[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: big memory leak in GSString
From: |
Fred Kiefer |
Subject: |
Re: big memory leak in GSString |
Date: |
Tue, 8 Jan 2013 09:43:22 +0100 |
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.
Hope this helps
Fred
On the road
Am 08.01.2013 um 01:28 schrieb Pirmin Braun <address@hidden>:
> I've extended the test to reflect what happens in our App and now the problem
> shows:
> Code:
> #import <Foundation/Foundation.h>
>
>
> int
> main(int argc, char **argv)
> {
> NSString *s = @"fi-rst|sec-ond|thi-rd",*s1;
> 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]]));
>
> [[a1 objectAtIndex:0]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;
> }
>
> WO:
>> Running 'TestTool.exe'...
> Jan 08 01:16:43 TestTool[3952] a fi-rst has retainCount of 1
> Jan 08 01:16:43 TestTool[3952] b fi-rst has retainCount of 1
> Jan 08 01:16:43 TestTool[3952] c fi-rst has retainCount of 1
> Jan 08 01:16:43 TestTool[3952] after [s1 retain]: fi-rst has retainCount of 2
> Jan 08 01:16:43 TestTool[3952] after [pool release]: fi-rst has retainCount
> of 1
>> Finished running 'TestTool.exe'.
>
> GNUStep:
> s15351252:/usr/GNUstep/Local/Projects/TestTool#
> /usr/GNUstep/Local/Tools/TestTool
> 2013-01-08 01:19:55.434 TestTool[25320] a fi-rst has retainCount of 2
> 2013-01-08 01:19:55.438 TestTool[25320] b fi-rst has retainCount of 4
> 2013-01-08 01:19:55.438 TestTool[25320] c fi-rst has retainCount of 4
> 2013-01-08 01:19:55.438 TestTool[25320] after [s1 retain]: fi-rst has
> retainCount of 5
> 2013-01-08 01:19:55.438 TestTool[25320] after [pool release]: fi-rst has
> retainCount of 2
>
>
> the substrings of a substring retain their string from which they where
> splitted off;
> when those 2nd generation substrings are retained, the 1st generation
> substrings won't get deallocated;
> but they should, they are just intermediate objects;
>
> --
> 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
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
- 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 <=
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/08
- 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