tracking down reference counting memory leaks

[Michael Stahl]

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  :)