I ported over the disable-custom-memory allocator at runtime stuff to the new allocator that LibreOffice is actually using. Hopefully that doesn't break anything horribly on e.g. windows. That should make it easier to valgrind LibreOffice "out-of-the-box".
So I've documented a few little debugging notes for valgrind, cppunit, etc. at http://wiki.documentfoundation.org/Development/How_to_debug bottom line is that export G_SLICE=malloc disables at run-time the custom memory allocator if that wasn't disabled at build-time. (G_SLICE=malloc because that's the same one that glib uses, and so affects both sets of libraries in a good way for debugging purposes) export VALGRIND=memcheck will autoset G_SLICE to malloc and cause LibreOffice at-run time, and cppunit test, hunspell regression tests and the smoketest etc at build-time to be run under valgrind's memcheck We probably need to add some suppression files for the warnings in libs we don't control, e.g. various fontconfig versions and so on before causing valgrind to abort the build on a warning. caolanm->dtardon: could you fill in the current state of the --enable-debug=X ==> OSL_DEBUG_LEVEL stuff and toggling between then in there to that "How to debug" page. C. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
