urcu: memory leaks
I was tracking down a memory leak in a project I'm contributing to (using Valgrind) and it looks like some leaks exist in userspace-rcu.
Specifically calls to call_rcu() is what I am interested in.
I ran the tests included in userspace-rcu with Valgrind and noticed that there may be some other leaks as well. I've attached the exact tests I ran as well as the output.
Updated by Mathieu Desnoyers about 2 years ago
This message on the lttng-dev mailing list discusses the reason why liburcu's default call_rcu worker thread data structures are leaked at process exit, and hints at a possible solution:
Relevant snippet here:
I can see that maybe we could change liburcu to make it so that we free all call_rcu data structures _if_ they happen to be empty of callbacks at process exit, after invoking one rcu_barrier. That should take care of not leaking data structures in the common case where call_rcu does not enqueue further callbacks.
And relevant follow up reply:
Updated by Brett Holman about 2 years ago
Thanks for the response Mathieu. I believe that what was suggested in this discussion below would cover the current case that I'm seeing.
> > > I can see that maybe we could change liburcu to make it so that > > > we > > > free all > > > call_rcu data structures _if_ they happen to be empty of > > > callbacks at > > > process exit, > > > after invoking one rcu_barrier. That should take care of not > > > leaking > > > data structures > > > in the common case where call_rcu does not enqueue further > > > callbacks. > > > > > > Thoughts ?
Without diving into the current urcu implementation more I don't have any better suggestions to handle the callback-in-callback issue that was mentioned.
Updated by Mathieu Desnoyers 4 months ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
Applied in changeset userspace-rcu|1cf55ba47342156cdf25335264b9774a16e0bb2d.