Bug #1317
closed
Added by Brett Holman over 3 years ago.
Updated over 1 year ago.
Description
Hello!
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.
Regards,
Brett
Files
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:
https://lists.lttng.org/pipermail/lttng-dev/2021-April/029951.html
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:
https://lists.lttng.org/pipermail/lttng-dev/2021-May/029963.html
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.
- Status changed from New to Resolved
- % Done changed from 0 to 100
Also available in: Atom
PDF