Resolve memory leaks in ConcurrentMap, EpochManager, LockFreeStack, and LockFreeQueue #25928
Conversation
Signed-off-by: Jade Abraham <[email protected]>
Signed-off-by: Jade Abraham <[email protected]>
Signed-off-by: Jade Abraham <[email protected]>
| @@ -568,7 +576,8 @@ module ConcurrentMap { | |||
| :yields: A copy of one of the keys contained in this map. | |||
| */ | |||
| iter keys() : keyType { | |||
| for (key, _) in this { | |||
| // dummy variable to workaround: https://github.com/chapel-lang/chapel/issues/25926 | |||
There was a problem hiding this comment.
I guess this is an issue you discovered while working on fixing the memory leaks here?
Assuming we don't already have a future for this, it'd be a nice thing to add. We have some job that tracks our "known memory leaks" so it would be good if that kept track of this.
AFAIK, @e-kayrakli is more familiar with what you'd need to do to make a future / failing test or whatever that would get tracked by that job.
There was a problem hiding this comment.
For a test that is known to be leaking for something we are aware/have to accept, just add --memLeaks in its execopts so that it'll always print the leak table. Add the leak table to the good file, and prediff the memory addresses printed on it. See test/memory/ferguson/test1 for an example.
There was a problem hiding this comment.
Yeah I found this bug while working on this, I just pushed a future
Signed-off-by: Jade Abraham <[email protected]>
Resolves all of the memory leaks that are exposed by our current tests in the ConcurrentMap, EpochManager, LockFreeStack, and LockFreeQueue modules
While working on this, I also found #25926 and this PR adds a future for that.
Testing
[Reviewed by @stonea]