Re: Please test pending bugfix release of base

[Ivan Vučica]

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[])
> {
>       CREATE_AUTORELEASE_POOL(pool);
>       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

ivan@vucica.net