Re: Please test pending bugfix release of base

[Richard Frith-Macdonald]

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

> Hi Richard,
> 
> Le 16 juin 2011 à 09:58, Richard Frith-Macdonald a écrit :
> 
>> It's long enough now since the last release that I'd like to make a bugfix 
>> release of the base library (going from 1.22.0 to 1.22.1).
>> This release is mostly for portability issues, but there are fixes to atomic 
>> operations used for retain/release safety, which would be important to 
>> threaded software, so we really should make a release for tis alone.
>> The idea is not to add any new features, just to make things even more 
>> reliable and portable.
>> 
>> Please could people (especially those with unusual hardware and/or 
>> obscure/old operating systems) give this a try so we can make this release 
>> as portable and reliable as possible.
>> 
>> You can get hold of the pre-release code using subversion from 
>> svn://svn.gna.org/svn/gnustep/libs/base/branches/stable
>> If there is anyone who really can't use subversion but would like to try 
>> this, please let me know and I'll send you a .tar.gz archive of the source 
>> (approx 3MB email).
> 
> 
> Base seems to work pretty well in my case currently.
> 
> 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.