Is there any tips to avoid crashing of iPhone applications. Sometime it is very difficult to understand where the problem is.
What are the possible reasons of iPhone app crashes ?
One of the biggest causes of crashes on the iPhone platform is not following the Cocoa Memory Management rules.
See this question: Memory Management in Objective-C
Crashes are caused by bugs in your code. To prevent these you need to:
(a) learn how to write robust code
(b) learn how to test your code (with particular attention to stress testing)
(c) learn how to debug
This is not specific to the iPhone-platform, but what helps a lot is catching (proper) exceptions and logging the exceptions-messages somewhere so you know what went wrong and don't only get a "force close"-message with little or nor further information.
you should add NSZombie class to your project to avoid EXC_BAD_ACCESS errors... even this helps to understand what's happened. So to do it you should click on the Get Info of your Executables and then go to the Arguments and there you can add NSZombieEnabled with value YES and MallocStackLoggingNoCompact =1
Related
I have an app that is crashing on the device (works well in the simulator) which leads me to assume that maybe it's a memory issue...
When it crashes, there is no message whatsoever reported in the console.
It does not crash each time a certain action is taken, it crashes at different points of time always after the app has been running and in use for some time.
I know I'm supposed to ask a more specific question - but if anybody is able to tell me where to start trying to track down a crash that does not report in the console, I would really appreciate it!
I am now using the latest version of XCode (4.2)
Thanks in advance...
It very-well could be a memory issue. If that is where you want to start your diagnostics, you can use the built-in Xcode profiler. In Xcode Product->Profile will get you started.
Maybe setting the NSZombiesEnabled value to YES in Project -> Edit Active Executable -> Arguments -> Variables is also helping; this will show you memory access errors based on accessing released objects. But in that case you should at least get a SIG_ABRT or BAD_ACCESS error ...
You can also log when the app receives a memory warning in the didReceiveMemoryWarning functions of your view controllers - this is called before the system is throwing out stuff when memory gets low. That of course could lead to a crash with nothing showing.
First, relax.
Then read this Technical Note.
Now, follow these steps:
From /Users/<username>/Library/Developer/Xcode/DerivedData remove all folders.
From /Users/<username>/Library/Application Support/iPhone Simulator remove all folders.
Clean your trash.
Remove app from device.
Build and run application on device.
Follow the steps that leads toward a crash.
Now, go to XCode->Window->Organizer and select "Device Logs" your device from the DEVICES pane. Select the most recent of these which has your application's name. Wait for XCode to symbolicate the crashlog. There are two possibilities now:
Its a low memory crash.
Its a memory management related crash.
If its option one, profile your application in Instruments.
If its option two, you should see the stack frame where you application is crashing (or your module's stack). This SO question will be very helpful
If you cannot understand the output (or you think the crashlog is not symbolicating - or that its not your code that's crashing), please post the crash log's crashing thread's stack here and I'll look into it.
PS: in the first section we do the first two steps to make sure there are no left-over .app/.dSYM files which might hinder symbolication later in the process because XCode symbolicator is not that intelligent.
Is there a list of known leaks within the iPhone SDK sitting somewhere, all alone?
I guess you would have it specified by version. (I just ran my test app - it has a leak outside the project itself (somewhere related to connections) when testing it on a v3.3.1 iPhone 3G, but the leak is not there using an iPhone 4 v4.0.2.).
It's doubtful that there's a public list of known memory leaks. If you want to know whether your leak is a known issue, your best bet is probably to search Open Radar, or to use Apple's Bug Reporter and see if you get a response.
During my short experience with the iPhone SDK, I have never encountered a memory leak caused really by the SDK. It is mostly caused by your code but has shown itself later.
It is also possible that the new SDK has improved some ways of doing things, so that your previous leaks do not occur anymore.
You need to give more details to the leak in order to help you.
I have a superweird problem:
I get a crash (EXC_BAD_ACCESS) when running my app with Release as active configuration on my 3.1.3 iPhone 3G. (works well in debug configuration or in simulator , works perfectly on device running iOS4).
My first guess was one setting in the Release configuration was erroneous/missing. In order to test it I just made a duplicate of my debug configuration and surprisingly I get the same error (although configuration is just a copy of the one working).
I don't understand why, with configurations that are supposed to be the same, one is working and not the other one.
If someone want to enlighten me, I am banging my head against the wall.
Thank you
NOTE: base SDK is 4.0 and deployment target is 3.0
Perhaps you have an unassigned local variable. Object-C follows how C does this. So in a release version you cannot assume that any local variable is initialised to 0 whilst in debug you can (in this case I would guess a pointer).
EDIT:
Pass -Wuninitialized to the compiler (or better -Wall) for the compiler to warn on these Apple gcc man page Note only works if optimizer is on.
You should check for memory leaks and handling of memory warnings. The amount of memory is probably the biggest difference between the environments you quote.
In another scenario I once found out that the simulator was faster, and therefore a certain race condition didn't show up, which did show up on the device. That's the second difference in the environments you quote: speed.
Try to pinpoint your crash and investigate from there. NSLog all didReceiveMemoryWarnings. Look for places where you made assumptions, i.e. about static information.
I fixed the problem.
It was three20 library fault. I had updated to the master branch that support iOS 4 but unfortunately this breaks support for 3.1.3. (thing that is not documented apparently)
Anyway I found this post that helped me to spot the problem. I just had to apply this patch and then I was able to run my project on 3.1.3 devices and iOS4 ones
Weird thing: why was it crashing when I was initializing a UIActionSheet (on a line of code not related at all with the Three20 lib)?
Thank you for your help.
I have an iPhone app that's been in development for about 2 weeks. We recently tried the "release" version of the build on a device, and to our great unhappiness, it crashes in one of the views with an "EXC_BAD_ACCESS".
This crash only occurs on devices, and only in the "release" build. Not only that, but it only happens the first time the app is launched! It is also 100% reproducible.
We have removed the small block of code that deals with data persistence, and have tried re-openning Xcode, cleaning the project, deleting and reinstalling the app, etc., as some other questions suggest.
Do you have any advice for a) what might be causing this problem, and b) how to go about debugging if it only happens in "release"?
Thanks
It turns out there was no problem in the code at all.
The reason it was crashing was that Xcode was trying to attach the debugger to the release build for some reason! We are still trying to figure out why, because we have checked the most obvious places, but I'm sure it won't be too hard to track down.
The build works fine if you install from iTunes or the Xcode organizer instead of building and running from Xcode directly, so it won't affect your end-users at all, as long as you are careful to check for other first-run issues.
We can only guess what the cause might but if it's 100% reproducible, then it should be a good candidate for some fprintf-style debugging.
Figure out the most probable place for the error to occur, and start putting "Got past xxx view initialization" style statements in to start narrowing the problem. It's tedious, but eventually, you'll get there.
In theory fprintf statements could affect the problem. However, it's rare that it does so, so it's a good place to start.
First, Thanks to all for your quick help for any questions asked in this forum.
I just want to know what are the testing tools coming up with Xcode on Mac as i need to test my iPhone application professionally (or) What do you suggest to use debug and test my application using any (or) built-in tools?
Thanks.
The first thing I try is Xcode's "Build and Analyze" menu command.
Next thing is to run Instruments and look for memory and object allocations and disposal. Instruments should keep you busy for quite a while as it can provide you a wealth of information, including network performance and graphics utilization.
When using instruments, the first method you should check is memory allocation and leaks. When your application leaks, it will spike. Click on this leak and then extend the details to find the exact whereabouts of the leak.
However read the documentation on it all first.
Documentation