问题
Running a long-running sound processing app on tethered (to Xcode 3) iPod Touch. Twice now, after 1 hour 40 minutes the first time and 2 hours 20 minutes the second, the app has ended with signal 0. There are multiple discussions of signal 0 here and on other forums, and they all seem to blame running out of memory.
But I dump the memory used at intervals, and, on the last test, it grew only about 3.3mb from early in the run until just before the end. And I have a hook in my app delegate to log if I get a memory warning (tested it on the simulator) and it did not get triggered.
In short, there's no suggestion of an out-of-memory condition.
In both cases the application was ended at a point in the program where files are written and transmitted to a server. (This occurs every 20 minutes.) The files being transmitted are relatively small (86kb for the one being transmitted at the point of failure). Based on the logs, it appears that the failure may have occurred while reading the file to prepare for transmission. This would have involved creating an NSString containing the data to transmit. (Probably the logic here could be a little cleaner -- it's using NSString stringByAppendingFormat, which is, I'll admit, suspect.)
Any suggestions on how to debug this? Does it ring a bell? Could I be getting out of storage without any warning? Is there something that could be "going to sleep" on the phone? Is there simply some limit to how long you can run a tethered test on Xcode 3?
回答1:
I can only suggest that you wrap with NSAutoreleasePools all your code that uses autoreleased objects created in loops. Every autoreleased object that you create is added to the main autorelease pool thus the overall memory allocations are getting bigger and bigger till the system gives you memory warning and closes your app.
Here is more about NSAutoreleasepool:
http://www.cocoadev.com/index.pl?NSAutoreleasePool
Or here from docs:
You may create an autorelease pool inside the loop to dispose of those objects before the next iteration. Using an autorelease pool in the loop helps to reduce the maximum memory footprint of the application.
That is only a guess but from my experience, adding custom pools let's you effectively minimize the memory allocations. Hope it helps.
回答2:
I'm not sure this is the final answer, but I've "massaged" the code for the last couple of days and fixed several storage-related problems. Several small leaks were fixed ("Leaks" is an invaluable took, but the interface kinda sux), but, more importantly, I fixed one place in the code (alluded to in my original post) that was likely allocating 100mb or so in one method. The storage was all autoreleased, but that still meant it created a substantial hump in the allocation curve. (And where this all happened corresponded pretty closely to where the crash occurred.)
After these fixes the app ran for over 3 hours -- not quite ready to declare victory, but it's looking good.
(The ugly code (not mine!) was using stringByAppendingFormat repeatedly to build up a relatively long string for network transmission. If you have N strings of length M to concatenate together, and you use stringByAppendingFormat repeatedly to do it, the result is about N*M, but you spin through about N*N*M/2 storage to build it. If N is on the order of 2000 that gets to be a big number. And though it's all autoreleased it still accumulates until the pool is drained. Using the append functions of NSMutableString is much more efficient.)
来源：https://stackoverflow.com/questions/8511213/program-received-signal-0-no-prior-sign-of-trouble