[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 00:21:20 +0100 |
Am Mon, 7 Jan 2013 23:06:22 +0000
schrieb Tom Davie <address@hidden> :
>
> On 7 Jan 2013, at 22:50, Pirmin Braun <address@hidden> wrote:
>
> > Am Mon, 7 Jan 2013 22:28:13 +0000
> > schrieb Tom Davie <address@hidden> :
> >
> >> Instead, simply try to reduce this to a simple test case in which the
> >> string is not deallocated, yet all autorelease pools have been popped, and
> >> all allocs/retains balanced.
> >>
> >
> > ok, here I've got a simple test:
> > svn checkout -r HEAD --no-auth-cache
> > svn://svn.intars.at/intars/Local/Projects/TestTool --username anonsvn
> > --password 'intars'
> > cd TestTool
> > make install
> >
> > cd /usr/GNUstep/Local/Tools
> > ./TestTool
> >
> > -> 2013-01-07 23:49:17.336 TestTool[23179] TestTool: first has retainCount
> > of 2
> >
> >
> > wheras on WO windows it says
> >> Running 'TestTool.exe'...
> > Jan 07 23:35:45 TestTool[300] TestTool: first has retainCount of 1
> >> Finished running 'TestTool.exe'.
> >
> >
> > the .m looks like this:
> > #import <Foundation/Foundation.h>
> >
> > int
> > main(int argc, char **argv)
> > {
> > NSString *s = @"first|second|third",*s1;
> > NSArray *a;
> > NSAutoreleasePool *pool =[NSAutoreleasePool new];
> >
> > a = [s componentsSeparatedByString:@"|"];
> > s1 = [a objectAtIndex:0];
> >
> > NSLog(([NSString stringWithFormat:@"TestTool: %@ has retainCount of
> > %i",s1,[s1 retainCount]]));
> >
> > [pool release];
> > exit (0);
> > return 0;
> > }
>
> This test is not demonstrating anything beyond a different implementation of
> componentsSeparatedByString:. s1 is retained by *at least* a, it may also
> (and likely is) be retained by the autoreleasepool until it is drained.
>
> Now try retaining s1, and logging the retain count after the autoreleasepool
> drain.
ok, Code:
#import <Foundation/Foundation.h>
int
main(int argc, char **argv)
{
NSString *s = @"first|second|third",*s1;
NSArray *a;
NSAutoreleasePool *pool =[NSAutoreleasePool new];
a = [s componentsSeparatedByString:@"|"];
s1 = [a objectAtIndex:0];
NSLog(([NSString stringWithFormat:@"%@ 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 00:12:20 TestTool[2260] first has retainCount of 1
Jan 08 00:12:20 TestTool[2260] after [s1 retain]: first has retainCount of 2
Jan 08 00:12:20 TestTool[2260] after [pool release]: first has retainCount of 1
> Finished running 'TestTool.exe'.
GNUStep:
s15351252:/usr/GNUstep/Local/Tools# ./TestTool
2013-01-08 00:15:47.400 TestTool[23737] first has retainCount of 2
2013-01-08 00:15:47.405 TestTool[23737] after [s1 retain]: first has
retainCount of 3
2013-01-08 00:15:47.405 TestTool[23737] after [pool release]: first has
retainCount of 1
you're right, looks like the autoreleasePool retains the object in GNUStep;
--
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 <=
- 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, 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