[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please test pending bugfix release of base

From: Ivan Vučica
Subject: Re: Please test pending bugfix release of base
Date: Sat, 18 Jun 2011 13:54:38 +0200

On Sat, Jun 18, 2011 at 09:41, Richard Frith-Macdonald <rfm@gnu.org> wrote:

On 17 Jun 2011, at 11:39, Quentin Mathé wrote:

> Hi Richard,
> However what I observe is that valgrind reports many memory leaks, even with a progam that does nothing (see code below), and this means it's hard to track down a memory corruption with valgrind. The output becomes really huge (several MB) when you run a real application or tool.
> #import <Foundation/Foundation.h>
> int main (int argc, const char * argv[])
> {
>       DESTROY(pool);
>       return 0;
> }
> Here is the valgrind output with 'valgrind --leak-check=full' for the progam above: http://60gp.ovh.net/~dromasof/gnustep/base-valgrind.log

Yeah ... we create a load of data structures and cache a load of stuff, all of which is fine and right for performance, but that *does* make it harder to sport real leaks.
I've toyed with the idea of providing a standard mechanism to register objects in some way rather than storing them in static variables, so we could (when in debug mode) release all such registered objects from an atexit handler.   Of course, going through all the codebase and changing all the deliberately 'leaked' data to be registered that way would be a large undertaking for no operational gain ... but the advantage for tracking leaks is big enough that I'd be prepared to devote some time to it.

Is it possible to programmatically tell valgrind to stop and start tracking leaks? If it is, and all the caching is grouped in some way (for example, during runtime initialization, or during -[NSAutoreleasePool init], or during +initialize methods), it may be possible to tell valgrind not to track those "leaks" in production builds.

Ivan Vučica

reply via email to

[Prev in Thread] Current Thread [Next in Thread]