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
- [Libreoffice] Added some docs on valgrind/debugging · Caolán McNamara
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.