Open Radar

 
Summary:
There appears to be a pretty significant leak of NSPathStore2 elements in SKTextureAtlas through the findTextureNamedFromAtlas method which I'm assuming is always called internally via the textureNamed method.  In our tests, we've seen this climb as high as 1GB.  Additionally, all one needs to do to trigger the bug is simply call textureNamed.  You don't need to use the resulting SKTexture, and ARC does nothing to cleanup any resulting unused resources.

The attached repro project demonstrates what happens when you access this API.

Steps to Reproduce:
1. Open the attached project in Xcode 5.0.
2. Run the project either in a simulator or on an actual device.
3. In the debug session, transfer debugging to Instruments.
4. Switch the Statistics to Call Trees.
5. Select the "Show Obj-C Only" call tree.
6. Begin clicking on the simulator view (or tapping the device's screen) repeatedly.  The more times you do it, the more evident the leak becomes.
7. Expand the -[SKTextureAtlas textureNamed:] tree.
7.1 Expand the -[SKTextureAtlas findTextureNamedFromAtlas:] tree.
7.2 Expand the -[NSString(NSPathUtilities) stringByDeletingPathExtension] tree.
8. Note the amount of memory that +[NSPathStore2 pathStoreWithCharacters:length:] method is using.

Expected Results:
textureNamed should return the sprite we need without leaving any resources required during the loading process of the sprite lingering in memory afterwards.  Furthermore, ARC should be able to release any unused resources.

Actual Results:
textureNamed instead will leave NSPathStore2 objects lingering in memory.  We've made every attempt to try and reduce the chances of this happening, such as making use of autorelease pools, but thus far nothing has had an impact.  Additionally, the leak actually seems to be occurring with NSPathStore2 in general, and any objects that make use of that API (or APIs that use it) don't seem to be removed from memory when they're no longer accessible.

Version:
7.0/11A465

Attachments:
http://cl.ly/3X1D0N1v2A2z