On Wed, 2011-06-22 at 11:44 +0100, Michael Meeks wrote: > Which makes me wonder ... should we not include the BSD licensed, > valgrind remote header into our build, and use the magic traps to detect > it ?
The pool allocator stuff which G_SLICE disables has memcheck markup in it already, it already gets used if the valgrind headers are available at build-time so in theory we could just stuff the header in unconditionally and always build with memcheck-detectable memory pool foo. Unfortunately, there's either a bug which valgrind/memcheck detects in the pool allocator, or the markup isn't quite right, haven't had the time to debug it closer. IIRC you'll get "I bet your memcheck allocator markup is wrong" messages on app exit with /usr/include/valgrind/memcheck.h present when you compile sal and run under valgrind without G_SLICE set if someone wants to have a look at that. grep for VALGRIND in sal/rtl/source to have a look at the markup in case it looks obviously wrong to anyone. > a single method: > > bool running_under_valgrind (void); > or > bool running_under_memcheck (void); > > so we can switch our allocation semantics auto-magically. That's fine for *our* allocator, but we make a fair bit of use of glib/gtk2 stuff, we picked G_SLICE to turn off our mempool allocator, because that's what glib uses to turn off its mempool allocator so we can turn the whole stack memcheck friendly in one swoop. C. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
