Re: tracking down reference counting memory leaks

On 21.10.2014 12:07, Noel Grandin wrote:
> 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

possibly backtrace_symbols - but we do want to have de-mangled C++
function names, since the approach generally requires manual analysis
and you want to be able to quickly discard obviously wrongly detected leaks.

> > 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?

there are still some problems with it - it actually requires a global
mutex to prevent concurrent access to the dummy allocation map, and it
ran into a deadlock with some configmgr debug code that is run from a
queryInterface() implementation; also the PythonTest_dbaccess_python
can't load the JVM, no idea why that is (or whether that problem exists
on master too, am doing a rebuild without the patch now).

oh, and as i just found, if some code foolishly just does a manual call
of acquire() without a matching release() then the second approach can't
detect it, so the first one is useful after all  :)