As per request by Michael M:
All of my past contributions to LibreOffice may be licensed
under the MPL/LGPLv3+ dual license, including the go-oo code.
Julian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.o
> 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 (
> 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 practi
On Wednesday, June 22, 2011, Michael Meeks wrote:
> But a single method:
>
> bool running_under_valgrind (void);
> or
> bool running_under_memcheck (void);
>
> so we can switch our allocation semantics auto-magically.
>
> Julian - we have lots of complex stuff; how
On Wednesday, May 11, 2011, Norbert Thiebaud wrote:
> On Tue, May 10, 2011 at 9:42 AM, Michael Meeks
wrote:
> > Hi Norbert,
> >
> >Julian tells me that valgrind works nicely on Mac;
>
> Indeed. I just downloaded the lastest source tarball...
> ./configure/make/make install straight up,
(speaking from a position of zero knowledge of LO's threading
stuff, but having spent way too much time chasing threading gunk
in general ..)
Michael Meeks wrote:
> > So - I'm with Kohei mostly - lets not do over-expensive,
> > non-inline-able nonsense atomic operations when we don't need to.
At FOSDEM'11 there was some mumbling about LO's regression tests
taking two days to run due to some timeout kludgery necessitated by
occasional hangs at exit due to possible threading bugs. Or something
like that. I can't remember exactly.
Recently I've been improving Valgrind's Helgrind tool a
> gtk a11y stack, while the initial helgrind ones end on in gdbusprivate.c
> etc.
The reports of races are not going to be accurate unless Helgrind sees
all the sync events done by the lower level libraries. If they just use
the pthread_ primitives that's fine, but if they roll their own locks
e
On Thursday, March 31, 2011, Caolán McNamara wrote:
> The first one at least seems to be the common enough pattern we have
> where we grab our global mutex when initializing singletons on first
> use/creation e.g.
>
> const Class& foo()
> {
> static Class aFoo;
> if (aFoo.uninit) //ne
At FOSDEM'11 there was some mumbling about LO's regression tests
taking two days to run due to some timeout kludgery necessitated by
occasional hangs at exit due to possible threading bugs. Or something
like that. I can't remember exactly.
Recently I've been improving Valgrind's Helgrind tool a
10 matches
Mail list logo
