Reading more carefully, it seems the #undef block at the bottom of a
recent svn's valgrind.h doesn't match the similar undef at the top - is
that intended ? [seems to miss eg. the s390 piece].
oh, our snafu. will fix.
Caolan - what do you think of doing:
[...]
+ if (RUNNING_ON_VALGRIND)
+ {
+ putenv ("G_SLICE=1");
+ fprintf(stderr, "LibreOffice: running under valgrind
detected.\n"); + alloc_mode = AMode_SYSTEM;
+ }
Doesn't that give a potentially bad effect, that any lib-gnome-goop
library allocations that happen before that point will get done by
gnome's custom allocator, but it will subsequently get freed by the
system allocator? Sounds like the express train to Segfault City Central.
Even if that doesn't fail .. wouldn't we wind up with a bunch of allocs
(prior to this point) that Memcheck doesn't know about, and a bunch
that it does? That don't sound good.
J
Context
- Re: [Libreoffice] crash in escherex.cxx in master (continued)
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.