Re: tracking down reference counting memory leaks

On 2014-10-20 06:27 PM, Michael Stahl wrote:
> there are 2 ways i've tried to track down the 2 leaking acquire()s:
>
> 1. instrument the acquire()/release() method and run the test in gdb,
> the script just takes 2 minutes to run (90 seconds of which are spent in
> a single regex) but unfortunately printing 4000 stack traces with gdb
> takes > 3 hours on my laptop; probably that can be sped up by disabling

The backtrace API in GLIBC would speed this up considerably
http://www.gnu.org/software/libc/manual/html_node/Backtraces.html

> 2. instrument the uno::Reference class so that every acquire()/release()
>
> ... is the gerrit patch; it can detect only uno::Reference leaks, but
> requires further work to detect rtl::Reference, uno::Any (and maybe
> uno::Sequence and whatever other weird things?) too.

But I think this approach is much nicer. Very neat!

Perhaps we could compile it in for --enable-dbgutl
but only activate it when doing the valgrind run, perhaps with some sort of environment flag?

Regards, Noel