View Issue Details

IDProjectCategoryView StatusLast Update
0007626GNUnetrevocation servicepublic2023-02-06 05:44
Reporterulfvonbelow Assigned Toschanzen  
PrioritynormalSeveritytrivialReproducibilityhave not tried
Status closedResolutionduplicate 
Product VersionGit master 
Summary0007626: (Potential?) memory leak in gnunet-service-revocation
DescriptionThe only place most of the cleanup is done is in shutdown_task, but this task isn't added until some time later. Between when resources start being allocated in run() and when shutdown_task is added, there are several opportunities for failure that involve running GNUNET_SCHEDULER_shutdown. These sites don't free the resources allocated thus far.
Steps To ReproduceInspect run() in src/revocation/gnunet-service-revocation.c.
Additional InformationLikely not an actual problem outside of sanitizers, since the cases where these resources aren't freed involve immediate shutdown and presumably termination of the service itself somewhat promptly. Also because these resources are only allocated once.

shutdown_task is written to assume almost nothing except that revocation_map is non-null. We can easily move its addition up to immediately after revocation_map is set. Patch attached.
TagsNo tags attached.

Activities

ulfvonbelow

2023-01-30 00:57

reporter   ~0019713

Hm, apparently attaching a file is considered a separate action from opening the issue. It successfully created the issue, but then blocked me for an hour because it thought I was spamming, and I ended up creating a duplicate issue an hour later since I didn't know this one had succeeded. Anyway, consider the later one the canonical issue and this one should be closed, if only I knew how...

Issue History

Date Modified Username Field Change
2023-01-29 21:18 ulfvonbelow New Issue
2023-01-30 00:57 ulfvonbelow Note Added: 0019713
2023-02-06 05:44 schanzen Assigned To => schanzen
2023-02-06 05:44 schanzen Status new => closed
2023-02-06 05:44 schanzen Resolution open => duplicate