Re: Please test pending bugfix release of base

[Quentin Mathé]

Le 18 juin 2011 à 09:41, Richard Frith-Macdonald a écrit :

> 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.

I think that would be great. 
Also if there is a such standard mechanism to know which "static" variables are 
associated to which class, this makes possible to create multiple instances of 
a class at runtime. I think that could open up interesting possibilites with 
Étoilé's LanguageKit. For example, class hierarchy inheritance becomes possible 
(you just copy a class and its subclasses) and we could implement features like 
modules in a new language (for example, see 
http://bracha.org/newspeak-modules.pdf). 

Cheers,
Quentin.