I have an iPhone app that is crashing without explanation. After reading that Autorelease pools are ill advised for iOS I went to search them out in my app and have discovered three (including one in main.m and one in a NSThread).
What exactly do I need to do to eliminate these from my code?
Thanks!
EDIT 1
I am printing, but can't see why it's crashing. Basically I start a thread which calls a method and then the app crashes. The first thing the method is set to do is to print to the console (with no values, just to show that the call worked), but it doesn't even get to that point. Very strange. Any ideas on how I could debug this?
Where did you read that autorelease pools are ill advised? I suggest you find some better sources of information.
Granted, you shouldn't be using autorelease pools haphazardly, and improper usage can cause problems, but certain situations require them. At a minimum, that one you found in main.m should be there. As should the one you found in your NSThread. It is very unlikely that they are responsible for your crash, assuming that your code is using them correctly.
When you application crashes do you get anything at all when running in debug mode? Any stack trace in the console, or log messages talking about memory warnings? Does the app crash randomly or only after performing a particular action? More information and/or code would be useful.
Autoreleases that are part of the iOS templates are not the problem. Autorelease pools are often necessary, and may not be why your app is crashing.
To address your problem
Add NSLog statements to your code to try and find out where your app is crashing
Use Instruments to detect memory problems and leaks
You may be over releasing objects. Here's an excellent Memory Management Guide.
Autorelease in main function and in new thread is required as per apple documentation. because when app launch some memory is reserved for launching the app. and if autorelease pool rempoved from the main function memory leak will be shown by simulator same in creating new thread.
Autorelease pools are required and the presence of an Autorelease pool is certainly not your problem. If your app is failing without a helpful log, try setting a breakpoint on exceptions.
http://developer.apple.com/library/mac/#documentation/IDEs/Conceptual/Xcode4TransitionGuide/Debugging/Debugging.html
Related
It's a weird situation for me that I cannot run my project on device or emulator but when I choose profile instead of run option, the app run flawlessly without any zombie guys.
It happens after I convert my project to ARC. I just modify code as Xcode tell me todo and due to the size of this project, I cannot look through every line of code.
ps. I'm the third hand on this application, so it's almost impossible for me to understand 10k lines of code.
Have you tried enabling Zombies in Xcode itself without profiling? This will set objects to never dealloc so that when you message an object that has a zero retain count, it will know what the object is and tell you. Just make sure you turn it on again so that objects will dealloc as normal.
See how to do that here:
How to enable NSZombie in Xcode?
the following can help you after the fact, but it's best IMO to perform them before migration; if a problem exists, ARC will solve some issues while abstracting others from you:
1) Create more Autorelease Pools one approach which might help you narrow things down is to explicitly create autorelease pools -- this can help localize some of your app's memory related issues. explicitly adding autorelease pools has other benefits, so this can be done not only for bug-seeking.
2) Use GuardMalloc as well, there are other memory related tools -- your app should also run fine with GuardMalloc enabled. switching to ARC could change the point of destruction -- you may be holding on to a dangling pointer.
3) Remove all Leaks finally, this may sound backwards -- remove all leaks possible. you want memory operations and lifetimes well defined. if you have an occasional leak, your issue could be hard to detect. oftentimes, reducing leaks can help you isolate the problem by making the problem easier to reproduce.
I have developed application and all is well. As well, I also keep memory foot print very low.No leaks show during application run. I tested application more than two hour and there is no crashing report. But when i checked application on instruments at that time it's show me following leaks.I have checked my app but there is no such leaking object. "Even I used app continue 12 hour and it didn't crash or stop".
//Here the screen shot of instruments.
///>>>>>>Here, I uploaded latest screenshot of leaks.It may help somebody to understand where the leak is.
// I think it's library file leaks(CoreFoundation)...Please Suggest What to do..
Please help me, This is really screw me up.
Thanks.
Not all of the 'memory leaks', are actual leaks. And some of the reported issues may be caused by Apple libraries themselves. Typically all the singletons, static variables, and some c level variables are 'leaked', but only once and are not considered a threat to memory.
Foundation classes such as NSString, NSArray, etc. are optimized to handle heavy workload. And some objects may be kept in the memory to be reused later. Such as #"".
So unless the issue is accumulating over time, just go for it, submit your app as it is. You still can fix it later, if necessary.
Hey analyze you code using "command+shift+b" and fix all leaks whatever coming after analyzing, submit it to app store. I don't think we can fix all leaks shown by instrument, so better to go with command+shift+b. I think we should use instrument only when getting memory warning and crashes due to insufficient memory.
I've been researching this throughout SO and some people said that this error is fine as long as the apps doesn't crash.
My app gets this error and after this when I try to tap on a row for a cell (calling didSelectRowAtIndexPath) it crashes. And it gives me an error UIImage sent message to deallocated message. I am guessing that this is because of the memory warning it has freed up some UIView's and therefore it crashes.
Why is this and how do I fix this? I've been debugging this for quite some time, using instruments, profiling, etc and had no luck.
I'd like to post some code, but don't know which one to post.
You have failed to retain something you cared about. From your message, I would suspect the object is a UIImage. Start by running the Static Analyzer and see if you're unretaining something obvious. Then inspect your ivars, particularly ones that are related to images. Make sure you access your ivars using accessors and not directly (except in init, the accessors themselves and dealloc). Make sure your object properties are defined with "retain".
You can use the "Zombies" instrument to help you track down which object is under-retained.
by one of your comments, it is very clear that the issue is with memory management and releasing your objects.... I suggest you to go a bit deep into your code and find out the code snippets where you are releasing you objects(or allocating them)... It can also be due to the fact that you are not at all releasing your objects after allocating and the processor trying to kill your app due to the lack of memory...And by the way, this kind of erros suck your time a lot... good luck...
Another memory question on iPhone - When running the leaks application I see a number of leaks get identified, but are caused by NSFoundation or similar, rather than my application code. Where my application name is mentioned, I have obviously resolved the leak.
I assume I can ignore these and that my app will be approved, or am I reading the data incorrectly?
Also - does the application have to have zero memory leaks before it is approved?
Cheers
Memory leaks will not cause your application to be rejected unless they contribute to general instability - e.g. a leak while moving forwards/backwards between views will eventually cause your app to crash.
Thats said, there are few actual leaks in the SDK libraries so be sure to check the leak are not actually a result of something your code is doing.
Any leaks that apple finds in testing of its own stuff will get fixed (and Apple does definitely test for leaks). The frameworks are not completely leak free, but it's dangerous to assume that a problem is in the frameworks. Here are a couple things to keep in mind:
(1) If you leak an object, the entire tree of objects hanging off it will also be reported as leaks. Suppose an object of class NSPrivateWhosit that you've never heard is leaked. Does that necessarily make it Apple's problem? No, it might be something used by an instance of NSPublicClass that you leaked.
(2) If an object is allocated in Foundation and passed to you, and you retain it, then you can leak it. The backtrace of the allocation doesn't matter. What matters is the backtrace of the unbalanced retain.
Your application will get approved even with memory leaks (at least my buggy application did get approved).
I added NSZombieEnabled to my executable's environment in order to track down an object that I'm over releasing. What I'm finding now, is that a part of my app is crashing that never has crashed before, only when NSZombieEnabled is toggled on. The moment I disable it, no crash occurs.
I need to do forensics on my code, but what can this possibly imply? NSZombieEnabled keeps objects around that are being sent the release message. This might be causing me to crash, but should it?
Also, setting the breakpoint -[_NSZombie methodSignatureForSelector:] doesn't really give me an elaborate enough stack trace to know what's going on.
If your app crashes with NSZombieEnabled, there's a good chance it crashes with it disabled, just not as soon and not as obviously.
NSZombieEnabled keeps objects around that are being sent the release message. This might be causing me to crash, but should it?
No, it doesn't cause you to crash. What causes you to crash is sending too many release messages to an object. That's what NSZombieEnabled is for.
Also, setting the breakpoint -[_NSZombie methodSignatureForSelector:] doesn't really give me an elaborate enough stack trace to know what's going on.
Try using the ObjectAlloc preset in Instruments.
Under NSZombieEnabled, objects are not fully released, they just become zombies. This means that memory can accumulate while you run, particularly in loops where you might be generating a bunch of NSStrings or the like. Your application may be getting killed due to memory usage.
I made the mistake of turning this on and forgetting about it, then spent the longest time trying to figure out why my memory usage kept increasing when I didn't have any obvious leaks.
One possibility: It could be that you're accessing an object through an invalid pointer and lucking out that another compatible object happens to be placed there. In that case, NSZombie would prevent the object from being replaced by something compatible and instead put a Zombie in its place.