Incorrect usage of NSAutoreleasePool in XADArchiveParser

[GoogleCodeExporter]

In the XADArchiveParser method 
addEntryWithDictionary:retainPosition:cyclePools:, if the cyclepools argument 
is YES, a new NSAutoreleasePool is created at the end of the method, and never 
released. According to Apple's documentation 
(http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundatio
n/Classes/NSAutoreleasePool_Class/Reference/Reference.html) one should always 
release a NSAutoreleasePool in the same context in which it is created, which 
is not happening in this instance.

I'm not entirely sure why the pool is created here in the first place, but it 
is definitely causing a leak when it happens. Disabling the creation of the 
pool altogether (thus making the cyclepools argument useless) solves the 
problem. I'm not sure what purpose it was originally intended to have, but it 
is certainly not correct the way that it is.

Original issue reported on code.google.com by bluecrab on 1 Oct 2011 at 9:42

[GoogleCodeExporter]

This is a somewhat wacky use of autorelease pools, yes, for somewhat 
complicated reasons. Most of the time, it is not used.

Autorelease pools are also nested, and can not in general cause leaks. Inner 
pools are released automatically when an outer pool is released.

Is this causing an actual problem anywhere?

Original comment by paracel...@gmail.com on 1 Oct 2011 at 9:49

[GoogleCodeExporter]

In a particular program that I'm writing that uses XADMaster, it is causing a 
leak. Its not necessarily causing a major problem in the program to have it 
leak the 48 bytes that the NSAutoreleasePool is taking up, but it is a bit of 
an annoyance while trying to debug it for other leaks.

Original comment by bluecrab on 1 Oct 2011 at 9:55

[GoogleCodeExporter]

Like I said, I don't think it should be possible in general to leak autorelease 
pools, so I am not sure what is going on there. I'll try to look into it at 
some point.

Original comment by paracel...@gmail.com on 1 Oct 2011 at 10:32

[GoogleCodeExporter]

If it helps any, I'm doing the unarchiving in a separate thread from the main 
thread (with a top-level NSAutoreleasePool in place in the thread). The thread 
exits soon after the unarchiving is complete.

Here's the actual method being run in that thread, that is showing the leak: 
http://pastebin.com/tSHgzGum 
Its probably not particularly useful, since its not a whole testcase, but maybe 
it'll help in some way? The method is spawned with [NSThread 
detachNewThreadSelector:toTarget:withObject], for reference.

Original comment by bluecrab on 1 Oct 2011 at 11:24

[GoogleCodeExporter]

I think I'll just declare that part of the code a failed experiment, since it 
never really went anywhere anyway, so I removed it. Hopefully that should fix 
it.

Original comment by paracel...@gmail.com on 24 Nov 2011 at 1:47

• Changed state: Fixed