Why is there a static NSString error?

Question

I have the following code to extract file paths in my iOS apps:

static const NSString * fullPathFromRelativePath(NSString *relPath) { // do not convert a path starting with '/' if(([relPath length] > 0) && ([relPath characterAtIndex:0] == '/')) return relPath; NSMutableArray *imagePathComponents = [NSMutableArray arrayWithArray:[relPath pathComponents]]; NSString *file = [imagePathComponents lastObject]; [imagePathComponents removeLastObject]; NSString *imageDirectory = [NSString pathWithComponents:imagePathComponents]; NSString *fullpath = [[NSBundle mainBundle] pathForResource:file ofType:NULL inDirectory:imageDirectory]; if (!fullpath) fullpath = relPath; return fullpath; } static const char * fullCPathFromRelativePath(const char *cPath) { NSString *relPath = [NSString stringWithCString:cPath encoding:NSUTF8StringEncoding]; const NSString *path = fullPathFromRelativePath(relPath); const char *c_path = [path UTF8String]; return c_path; } static const char * relativeCPathForFile(const char *fileName) { NSString *relPath = [NSString stringWithCString:fileName encoding:NSUTF8StringEncoding]; const NSString *path = fullPathFromRelativePath(relPath); const char *c_path = [[path stringByDeletingLastPathComponent] UTF8String]; return c_path; } 

I get quite a few messages like this in the debug console:

 objc[4501]: Object 0x6e17060 of class __NSCFString autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[4501]: Object 0x6e12470 of class NSPathStore2 autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug objc[4501]: Object 0x6e12580 of class __NSCFData autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug 

What is the problem with the code? (I even use iOS 5 with "automatic" save / release, etc.)

Greetings.

Answer 1

This message appears when you automatically validate an object in a thread that does not have release pools in its stack. By default, the main thread always has an autorun pool. It is created and managed in the UIApplicationMain() function, which is usually called by the main () function of your application. However, additional threads created by you (using performSelectorInBackground: or NSThread ) do not have an autoplay pool in place, unless you specifically impose it on it, so any objects with auto-implementation in this background thread do not have a pool for their release later and will just leak.

If you are kicking something in the background thread, the first thing you need to do is create an autostart pool. In ARC, use this @autoreleasepool construct to do this.

Answer 2

Have you tried using the same code in an application other than ARC? You can confirm if this is an ARC problem or a real structure error by doing this. ARC is still immature, Apple has repeatedly stated that it has not yet been completed and definitely has errors.

If you are concerned about the number of visible auto- @autoreleasepool {...} objects, create the @autoreleasepool {...} construct around the code in question. This is significantly more efficient than NSAutoreleasePool, which you still cannot create in ARC code.

Answer 3

I do not think this is a real leak. Apple discussed this several times, on the simulator it was a well-known pseudo-error in the way simulator libraries deal with NSAutoReleasePool, but not significant enough to guarantee a fix, since your Mac has significantly more memory than a device. At WWDC, they mentioned that there are several places where NSZombie doesn’t apply to auto-advertising correctly, but I don’t remember which session. If you do not notice a leak for these objects in the Tools, you should not worry about It. If you notice leaks using tools, write bugreport .

Do not create an autostart pool around your method just because it looks like it might leak. In ARC, which just won't work, and if you haven't changed your main () function of your application, you have the autorelease wrapping all package. Creating an additional pool of auto-calculations without profiling data that indicates that you have serious memory pressure after calling this method will actually make your application worse.

Answer 4

This happens if you delete calls to NSAutoreleasePool in the main.m file or if this code is executed in a separate thread. Since you cannot use NSAutoreleasePool with ARC, you need to put the stream code in the @autoreleasepool block