Re: [Libreoffice] crash in escherex.cxx in master

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.