On 08/09/2012 17:52, Norbert Thiebaud wrote:
On Fri, Sep 7, 2012 at 5:49 PM, julien2412<serval2...@yahoo.fr> wrote:
on this page http://wiki.documentfoundation.org/Development/How_to_debug
but what about if custom memory allocator is bugged? (BTW why do we use
this? Historical reason?) Wouldn't Valgrind be helpful to detect it?
I'm a bit lost here :-(
Julien,
A custom allocator will necessarily confuse valgrind... the only way
to 'unconfuse' it would be to teach valgrind about it and have
valgrind emulate the allocation mechanism of the custom allocator to
keep track of what is 'logically' allocated/freed... doing that would
be quite complex and the odd of doing a bug in the emulation layer is
much higher than the odd that there is a bug in the custom allocator
to start with...
So, in general, when using valgrind you _do_ want to disable any
'custom allocator'. and yes that won't help you find a bug in the
allocator... but if you have a bug, think horse not zebra... 99.999%
of the time your bug will have nothing to do with the allocator
itself.
Norbert
Thank you Norbert for your answer, it's clearer for me now. (moreover I
didn't know this expression, "think horse not zebra" :-))
So in
http://wiki.documentfoundation.org/BugReport#How_to_get_valgrind_log_.28on_Linux.29
page, should I add this:
export G_SLICE=always-malloc
before this:
valgrind --tool=memcheck --num-callers=50 --trace-children=yes ./soffice.bin
2>&1 | tee /tmp/valgrind.log
?
Julien
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
