tracking down reference counting memory leaks
mstahl at redhat.com
Tue Oct 21 06:59:01 PDT 2014
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
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 :)
More information about the LibreOffice