tracking down reference counting memory leaks

[nicholas ferguson]

>> ... but enough with the jocularities: there was this ChartModel that 
>> was leaked due to a uno::Reference cycle, which means that the usual 
>> tools like valgrind and address sanitizer aren't very useful as such.
> 
> I would expect
> 
> valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all
> 
> to be able to find this. But maybe I do not quite understand the problem.

>>it will of course tell you that your object is leaked.  but how do you
know which of the 1968 acquire() calls on it is the cause of the leak?

If your goal is to instrument a ref counting object to catch its memory
leaks... LibreOffice has too many modules that require static initialization
and makes debugging a single isolated class among its thousands of files...
crazy.  You are better off writing a multithreaded app that mimics the call
paths to ref counting and then replicate its memory leaking tendencies.

Ref has had some heavy handed bad coding in 'asserts'...that makes it
horrible to read during debug mode. A person keeps seeing a debug version of
LibreOffice crash and then has to spend days figuring out..who wrote the
idiotic asserts to crash it because oh my gosh..a ref count is incorrect.
How terrible!!! Crash this app immediately.  Bonkers

 IT becomes totally USELESS.  You are probably addressing that issue. Then a
debug assert that print out to log... 

#ifdef makeITSane.MakeCrazyGoAway
	override assert with this version
#else
CrazyGetstoStickAround

_______________________________________________
LibreOffice mailing list
LibreOffice at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice