[Libreoffice] crash in escherex.cxx in master
Julian Seward
jseward at acm.org
Thu Jun 23 02:52:09 PDT 2011
> 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
More information about the LibreOffice
mailing list