Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


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.


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.