tracking down reference counting memory leaks
noelgrandin at gmail.com
Tue Oct 21 03:07:53 PDT 2014
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
> 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?
More information about the LibreOffice