[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: big memory leak in GSString
From: |
Pirmin Braun |
Subject: |
Re: big memory leak in GSString |
Date: |
Tue, 8 Jan 2013 15:41:36 +0100 |
Am Tue, 8 Jan 2013 09:43:22 +0100
schrieb Fred Kiefer <address@hidden> :
> The behaviour in GNUstep is just as you describe, but this shouldn't lead to
> a real memory leak. The original string still will get released when the
> substrings get released. If the livespan of these strings should really be
> different, the best you can do is to copy the substring and work with the
> copy. This cuts the connection to the underlying parent.
>
ok, tried this:
#import <Foundation/Foundation.h>
int
main(int argc, char **argv)
{
NSString *s = @"fi-rst|sec-ond|thi-rd",*s1,*s2;
NSArray *a,*a1;
NSAutoreleasePool *pool =[NSAutoreleasePool new];
a = [s componentsSeparatedByString:@"|"];
s1 = [a objectAtIndex:0];
NSLog(([NSString stringWithFormat:@"a %@ has retainCount of %i",s1,[s1
retainCount]]));
a1 = [s1 componentsSeparatedByString:@"-"];
NSLog(([NSString stringWithFormat:@"b %@ has retainCount of %i",s1,[s1
retainCount]]));
s2 = [[a1 objectAtIndex:0]copy];
[s2 retain];
NSLog(([NSString stringWithFormat:@"c %@ has retainCount of %i",s1,[s1
retainCount]]));
[s1 retain];
NSLog(([NSString stringWithFormat:@"after [s1 retain]: %@ has retainCount
of %i",s1,[s1 retainCount]]));
[pool release];
NSLog(([[NSString alloc]initWithFormat:@"after [pool release]: %@ has
retainCount of %i",s1,[s1 retainCount]]));
exit (0);
return 0;
}
result on GNUStep:
2013-01-08 15:21:24.808 TestTool[30229] a fi-rst has retainCount of 2
2013-01-08 15:21:24.809 TestTool[30229] b fi-rst has retainCount of 4
2013-01-08 15:21:24.809 TestTool[30229] c fi-rst has retainCount of 4
2013-01-08 15:21:24.809 TestTool[30229] after [s1 retain]: fi-rst has
retainCount of 5
2013-01-08 15:21:24.809 TestTool[30229] after [pool release]: fi-rst has
retainCount of 1
so this works;
then implemented a new NSString Category method for the real world App:
- (NSArray *)copiedComponentsSeparatedByString:(NSString *)s;
{
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++){
NSString *s1 = [[a oai:i]copy];
[ma addObject:s1];
[s1 release]; // s1 only retained by ma which is autoreleased
}
return [NSArray arrayWithArray:ma]; // immutable
}
but unfortunately no impact on memory consumption;
background of all this: when creating a certain object by parsing a string it
takes 200 MB more than instantiating it out of an formerly archived instance
using NSArchiver/NSUnarchiver
--
Pirmin Braun - IntarS Unternehmenssoftware GmbH - Sinziger Str. 29a - 53424
Remagen
+49 2642 308288 +49 174 9747584 - skype:pirminb www.intars.de address@hidden
intars.sourceforge.net
Geschäftsführer: Pirmin Braun, Ralf Engelhardt Registergericht: Amtsgericht
Coburg HRB3136
- big memory leak in GSString, Pirmin Braun, 2013/01/07
- Re: big memory leak in GSString, Tom Davie, 2013/01/07
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/07
- Re: big memory leak in GSString, Tom Davie, 2013/01/07
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/07
- Re: big memory leak in GSString, Tom Davie, 2013/01/07
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/07
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/07
- Re: big memory leak in GSString, David Chisnall, 2013/01/08
- Re: big memory leak in GSString, Fred Kiefer, 2013/01/08
- Re: big memory leak in GSString,
Pirmin Braun <=
- Re: big memory leak in GSString, David Chisnall, 2013/01/08
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/08
- Re: big memory leak in GSString, Richard Frith-Macdonald, 2013/01/08
- Re: big memory leak in GSString, Chan Maxthon, 2013/01/08
- Re: big memory leak in GSString, Richard Frith-Macdonald, 2013/01/08
- Re: big memory leak in GSString, Fred Kiefer, 2013/01/13
- Re: big memory leak in GSString, David Chisnall, 2013/01/13
- Re: big memory leak in GSString, Fred Kiefer, 2013/01/13
- Partially solved: big memory leak in GSString, Pirmin Braun, 2013/01/14
- Re: Solved: big memory leak in GSString, Pirmin Braun, 2013/01/14