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

> 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.

In practice I find marking up with the memcheck macros is difficult
to make work well.  Even if you succeed in identifying the block
boundaries correctly, it tends to shout a lot when it sees the
allocator messing with the block metadata (freelist maintenance etc).
With a bunch of hoop-jumping you might be able to make it work, but
even then it tends to be fragile and have nasty corner cases, particularly
if you have any realloc-style stuff to annotate.

The simplest and most effective fix imo is to have some big switch
you can throw, that simply makes all allocation go via standard
malloc/free for the whole stack.  I've done tons of valgrinding of
Firefox, which has similar problems, and this solution works best.

> 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.

Right.  That sounds like a sane approach to me.  What's the element
of doubt here?

J