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 :) _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
