Re: big memory leak in GSString

[Fred Kiefer]

On 08.01.2013 16:42, Richard Frith-Macdonald wrote:
> On 8 Jan 2013, at 15:35, Pirmin Braun wrote:
>
> > Am Tue, 8 Jan 2013 14:51:07 +0000
> > schrieb David Chisnall <address@hidden> :
> >
> > > On 8 Jan 2013, at 14:41, Pirmin Braun wrote:
> > >
> > > >        NSString *s1 = [[a oai:i]copy];
> > >
> > > For an immutable string, -copy just calls retain.  If you want to actually copy 
> > > the string, do something like:

Not true for substrings, here copy generates a separate object that has 
no connection to the parent.

> > > NSString *s1 = [NSString stringWithUTF8String: [old UTF8String]];
> > >
> > > (for better performance, you might want to use getCharacters:range: and a 
> > > temporary buffer, so that the old string doesn't have to create a new 
> > > autoreleased buffer).
> > >
> > > David
> > >
> > > -- Sent from my STANTEC-ZEBRA
> >
> > ok, changed it like this:
> >     NSArray *a = [self componentsSeparatedByString:s];
> >     NSMutableArray *ma = [NSMutableArray arrayWithCapacity:[a count]];
> >     int i,j;
> >
> >     // deep copy of a
> >     for(i=0,j=[a count];i<j;i++){
> >         [ma addObject:[NSString stringWithUTF8String:[[a oai:i]UTF8String]]];
> >     }
> >     return [NSArray arrayWithArray:ma]; // immutable
> >
> > but also no difference; I give up. For the moment.
>
> You need to wrap things in an autorelease pool so that you can release the 
> array by releasing the pool ...
>
> 1. create pool
> 2. call -componentsSeparatedByString:
> 3. make deep copy of resulting array
> 4. release pool
> 5. autorelease and return the copied array

I spend quite some time to analyse the cause of Pirmin's problem. In the 
end it turned out that most of the memory was lost in the 
NSAutoreleasePool itself. We cache the instances of this class and when 
code uses a lot of objects with a single pool that pool will get huge 
and even after it is released that addition memory will be kept.
This is fine in the normal usage of auto release pools where we expect 
that the next usage will use about as many objects as a previous one. In 
Pirmin's case the auto release pool that gets used at the start up 
becomes huge and later on most of that memory is never needed again.

Of course the best solution is to use multiple auto release pools during 
the start up, for each operation a separate one. Still we should think 
about a way to get rid of these monster pools, when a badly written 
program generates one.

Fred