|
From: | Fred Kiefer |
Subject: | Re: big memory leak in GSString |
Date: | Sun, 13 Jan 2013 17:31:52 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2 |
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-ZEBRAok, 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
[Prev in Thread] | Current Thread | [Next in Thread] |