When an app suddenly quits and returns back to your home screen, can this always be dealt with alternatively with a try, catch block, or are there exceptions (other than memory leaks, too much memory) that can never be tried and catch, and result in the app quitting?
Many errors cannot be caught with try/catch. In most cases, you should not even attempt to. If you're throwing exceptions or causing a SEGV, then that indicates a serious problem that likely cannot be effectively recovered from. The correct behavior in a mobile environment is to terminate the app. Using tools like TestFlight you can try to recover the logs and stack so that you can resolve the bug.
The way to avoid crashing is careful coding and testing. You should not try to avoid it with a try block.
You need to find and resolve the cause of the app crashing, not just mask it with a try-catch around everything. To answer your question, "no".
Related
Have an app that's an iOS app with a Messages extension app. They share a significant amount of code related to calculating & editing the dimensions of some specialized objects and then using that to create paths for drawing.
The app was running perfectly. A build of the Messages app crashed with EXC_BAD_ACCESS code=2, seemingly within the code that's shared. No luck debugging it, as the location of the crash seemed to bounce around as I added log statements and refactored the code.
So I focused on the main app. First try was turning on Address Sanitizer, and that created the crashes discussed below. Then I edited the scheme to look for Zombies, and none were identified, including in Instruments. No memory leaks or other obvious allocation errors via Instruments. I edited the scheme to turn on Malloc Scribble, Malloc Guard Edges, and Guard Malloc, and the app ran fine with no crash or console log message.
So back to Address Sanitizer, which is the only option that caused the main app to crash, and it crashed in the same area as the Messages app. I figured if I solved one, I might solve both, and the app might be easier to debug without the complication of being an extension.
Every link I searched and read seemed to say that these Xcode diagnostics will (or should) identify the offending code, and in years of writing Swift, that's the typical case. This one has me stumped.
The main view controller is a UICollectionViewController, and the crash occurs at the very first collectionView(:cellForItemAt) call. There's nothing unusual about the other delegate calls, afaik, with normal (and accurate) counts and sizes. (And again, this is just with Address Sanitizer.) After getting the reusable cell, I call getObjectEffects with some default values (the app is more complex, but it crashed also on this ultra-simple hard-coded values case too, so I'm keeping the debugging as simple as possible), and the EXC_BAD_ACCESS is identified for the func definition of that function.
That's what stumps me. It's not identifying code where there's an assignment or allocation, but a func statement. And the parameters are Int and Bool. And there's zero output to the console, where I've also tried (lldb) command script import lldb.macosx.heap and (lldb) malloc_info —type 0x... with no result. As mentioned, I tried Zombies and the other Xcode memory management diagnostics with no insight into why Address Sanitizer is crashing at a func statement with an EXC_BAD_ACCESS, and I'm not sure how to diagnose this further.
What have I missed? Thanks for any insights.
Edit: Eventually made progress by switching code around and looking for different results. The eventual 'solution' is illogical in that I can't figure out how it should logically create any different result, but it does. And since it offers no insight into the original question of how to diagnose the cause of the EXC_BAD_ACCESS, I won't belabor it further here. For now, it'll be a 'solved' mystery.
I'm running into lots of instances with the latest version(s) of XCode (I believe this has been happening since 4.2 or so) where the stack trace when an exception is thrown is woefully devoid of details.
The screeshot here illustrates one such case; in fact, this scenario at least has SOME context (it shows me that it happened in the JKArray class), where many times I get nothing but "internal" stack items (just 2-3 entries in the thread, none of which reside in user code or anything I can look at). Even in this example, I don't know where the JKArray was allocated or released, so I have no idea what instance or where the problem is.
Thoughts:
I've tried adding a generic "on exception" breakpoint
There is some minor information available in the output; in this case: " malloc: * error for object 0x10e18120: pointer being freed was not allocated * set a breakpoint in malloc_error_break to debug". Doing this doesn't get me any further, though, since the breakpoint gets hit in the same stack as the exception...
I've tried switching to the other debugger
I've tried using my own custom exception handler
I've tried using the Profiler to look for leaks. There are no leaks that I can find.
No matter what I do, I can't seem to isolate the issues plaguing my app. Furthermore, the issues do not seem to be exactly the same each time, likely due to the high amount of concurrency in my app... so I'm left without a good way to fix the problems.
Edit: in the case of this particular exception, I did end up finding the cause. I had attempted to [release] and object that was [autoreleased]d. However, all of this was happening within my code; I can't understand why XCode would not give me a decent stack trace to help me find the problem, rather than forcing me to hunt through my whole app...
Sometimes it is impossible to pinpoint the real problem, because the issue that causes the symptom has happened much earlier.
Your issue provides a great example: when you release your object, cocoa has no idea that you've done anything wrong: you are releasing an object that you own, this is precisely what you should be doing, so there's no red flags. The code that leads to a breakdown is executed well after your method has finished, and gave the control back to the run loop. It is at this point that the run loop gets around to draining its autorelease pool, causing the second deallocation. All it knows at this point, however, is that the run loop has made an invalid deallocation, not your code. By the time the error happens the culprit is safely off the stack (and off the hook), so there is nothing else Xcode can report back to you.
A solution to problems like this is to profile your memory use: the profiler should catch issues like that, and pinpoint the places where they happen.
It goes without saying that switching to automatic reference counting will save you lots of troubles in the memory management department.
i used Bugsense framework in iPhone application to get the crashe logs, and it works fine.
but when i get the crash report from iTunes account, the crash report indicate that there is a crash in bugSense framework.
What this is mean? is it indicate that crashes in applications reported by bugSense ? or it is actual crash in the framework itself?
Please Help.
Thx
It could be, that this is a crash in their SDK. Sadly they perform non-async safe functions in their framework once the crash happened. See http://landonf.bikemonkey.org/code/objc/Reliable_Crash_Reporting.20110912.html for more details on what that means (in this case calling Objective-C code once a crash occurred is unsafe). You might want to contact them to make the fix this possible problem.
But the messages lower in the stack trace also indicate, that this is a crash that happened because of an uncaught exception occurred, which would normally cause another Last Exception Backtrace to appear on top of Thread 0. I am not sure if they have that functionality included. If they do, this causes that block only appear in their own crash report but not in the crash reports iOS creates. Then this is nothing to worry about, except that code above being bad as already mentioned.
If you have enabled immediate dispatch in BugSense, this is probably the reason of this crash, as it isn't guaranteed to be safe.
For more info you can check this: https://github.com/bugsense/plcrashreporter-bugsense/wiki/Using-the-BugSense-2.x-iOS-library , section Enabling immediate dispatch
this may happen when there is no internet connection, try enable immediate dispatch in bug sense
Is there anyway to implement a global exception handler for iPhone apps such that exceptions, instead of silently crashing the app, could allow for some sort of message?
I can understand if it's not do-able since the program may be in an inconsistent state, but it'd be nice to at least tell users "Sorry - something went wrong!"
Thanks!
Check this question for the answer. It seems to indicate that you'll be getting junky stack traces, but you definitely can set a global exception handler. Good luck!
I'm working on catching a seriously insidious bug that's happening in my code. The problem is, the bug is completely random and can happen either 9 minutes into the application's runtime or 30 minutes. I've gone ahead and added the fabulous PLCrashReporter to my project (http://code.google.com/p/plcrashreporter) and that works fine for trivial bugs. Also, when I'm in doubt, I will navigate to the crash logs found in ~/Library/Logs/CrashReporter/MobileDevice/ and run symbolicatecrash on the crash log. This + GDB will eventually catch any bug, except for the one I'm facing now.
Apparently the nature of this bug is preventing even Apple's crash logs to be properly written to storage. This shows when I sync my iPhone or iPod Touch with iTunes and run symbolicatecrash on my app:
sf$ symbolicatecrash foo.crash
No crash report version in foo.crash at /usr/local/bin/symbolicatecrash line 741.
It might be that my application is not leaving a crash report at all, and exiting due to memory issues. I do indeed see the applicationWillTerminate: executing my NSLog statement before exiting, in my App Delegate. However, after running the application through ObjectAlloc, my application never reaches > 2.08MB of usage. Although if I'm reading the results proper, I did allocate over 28MB of memory throughout the entire duration of my test run.
Thanks again for everything.
A couple of suggestions:
Make sure that you're not actually calling exit(), returning from main(), or otherwise cleanly exiting anywhere in your code. If your application is just quitting, and not crashing, that obviously won't leave a log.
I think that running the system very rapidly out of memory can sometimes cause your application to crash without leaving a crash log. Run it under Instruments and see what the memory usage over time looks like.
If you have a set of steps that "often" reproduces the problem, try running it under the debugger and poking at it until it does crash. That might be a half-hour well-spent.
Having eliminated the obvious/easy, it's on to the more-obscure. Chances are that you're corrupting your heap or stack somewhere along the way, via a buffer overrun, re-using an invalid pointer, etc, etc. Here are some things to try:
Try running with NSZombieEnabled=YES in the environment variables. This will help you find re-use of freed objects. It does have an enormous impact on memory usage though, so it may not be applicable for everyone. Here's an Apple article dealing with NSZombie (among other things).
When running in the iPhone Simulator, use the "Simulate Memory Warning" item in the Hardware menu to force a low-memory condition - this can flush out bugs in that code, which otherwise runs at unpredictable times.
Last but not least, do a search through your code for everywhere that you use low-level C memory manipulation functions - malloc, calloc, realloc, memcpy, strcpy,strncpy, etc - and make absolutely sure that the buffer sizes are appropriate.