I am using XCode 4.5 with LLVM. In older versions of XCode, when there was a crash it would give me meaningful debugging information. Lately I keep getting crashes that simply say "libc++abi.dylib: handler threw exception," and don't provide a stack trace that shows where the exception came from. This is totally useless to me. What are the proper debugging settings that I should set up so that I can find the location of the problem?
you could add a breakpoint and set it to break on all exceptions
Related
I'm new with Ios programming Objective-C language and my app was working great until suddenly stop working and get this error
Xcode show me a generic error and i want to know which function or instruction produce this error i couldn't find how to do this with Xcode i want just to point the problem where it may come from
This is the error i got :
Add Exception breakpoint
As shown in the image, select the 8th tab(Exception) and from the below add button, add the Exception Breakpoint. This will show the exact line of code from where the application crashes.
Add Exception breakpoint
How to create exception breakpoints in Xcode?
Exception breakpoints are a powerful debugging tool that remarkably
few people know about, so please read the following carefully and put
it into practice!
A regular breakpoint is on a line you specify and causes the debugger
to pause execution at that point so you can evaluate your program's
state. An exception breakpoint tells the debugger to pause whenever a
problem is encountered anywhere in your program, so you can evaluate
your program's state before it crashes.
Exception breakpoints are trivial to set up: go to the Breakpoint
Navigation (Cmd+8), then click the + button in the bottom left and
choose Add Exception Breakpoint. You can leave it there if you want
to, but it's preferable to make one further change to reduce
unnecessary messages: right-click on your new breakpoint, choose Edit
Breakpoint, then change the Exception value from "All" to
"Objective-C".
Please follow the below steps.
Run your project.
I am using Xcode 9.3. I was using Xcode 9.2.
In 9.2, when an exception occurred, the debugger showed the line that caused the exception in the editor area, and I would see the variables and their values, plus the console in the debug area.
I did not change anything, and yet, now, I get the stack trace in the editor area. Given that the error is a simple "found nil when unwrapping a variable" and is an explicit error in a single line of code, the stack trace is next to useless in finding this. In fact, in looking at the stack trace and variables, the only variable that is nil is not a variable that is created within the method that the stack highlights.
Since then, I have enabled Zombies. I have had to re-add an All Exceptions break point (why does it forget these between versions is a whole other question) set to "on Throw".
I have deleted Derived Data, cleans the build, restarted Xcode, restarted the Mac and made various rude gestures to my screen. The last helped a bit, however the rest achieved nothing.
Any further suggestions?
When i enable all exceptions breakpoint my app always stops in AppDelegate, but im able to continue the program execution, but its very annoying cause always takes me to the appdelegate. Any ideas why?
Only enable Objective-C breakpoints.
To see the actual statement that is causing the error add an exception breakpoint:
From the Main Menu Debug:Breakpoints:Create Exception Breakpoint.
Right-click the breakpoint and set the exception to Objective-C. This will ignore other types of exceptions such as from C++. There are parts of the APIs that use exceptions such as Core Data (Apple is Special).
Add an action: "po $arg1".
Run the app to get the breakpoint and you will be at the line that causes the exception and the error message will be in the debugger console.
Breakpoint example:
If you're using Swift, or you want to have all the exceptions captured, you can change an option on All Exceptions to automatically continue after evaluating actions. Just find it in the Breakpoint Navigator and right/ctrl click the all Exceptions Breakpoint to edit it:
Then check the Options box:
Exceptions in C++ code common and normal. The exception breakpoint catches every raised exception even when they are being handled correctly. So if you don't specify Obj-C only you will notice that execution stops in a lot of seemingly random places. I run into this all the time with AVAudioPlayer especially.
Another thing to look out for are missing assets. I came across this question from another asker who seems to have also run into the same issue.
Xcode throws an exception in Main() in iOS 8 with 'all exceptions' breakpoint
When I crash (for reasons I understand; that's not the problem) when I try to do something Cocoa isn't okay with, such as calling a method that doesn't exist or attempting to insert nil into a set, the debugger shows the stack from main() to __pthread_kill, without any of the frames that were present when the actual crashing code ran. There is a frame (9th from main) called objc_exception_rethrow. This leads me to believe that Cocoa Touch is trying to do something or other to recover all exceptions and die gracefully or something. However, it is very irritating when debugging to not have the ability to actually use Xcode4's debugging tools to investigate the calling stack frames, or even see where in my code I crashed.
Is there some way to make the objc_exception_rethrow behavior not happen, and just crash as soon as an exception is raised? Perhaps there's a debug setting that makes it crash earlier (at the right time)? (I haven't messed with any of the build settings in this project yet.)
I don't know any Xcode setting that could disable re-throwing exceptions. To my knowledge they are re-thrown by the runtime. You could try running the app without the debugger attached and let it crash. The crash report should contain a section "Last Exception Backtrace" which will give you exactly what you need in this case.
I found the answer: set a breakpoint on Obj-C Exceptions. It will go to the debugger when objc_exception_throw is hit, which is good. Unfortunately, this happens before the exception is printed, but we can make that happen anyway (most of the time) by setting the breakpoint's action to be (Debugger Action) po *(id *)($ebp + 8).
Our DUnit project is crashing on exit. It crashes if "Run Without Debugging", but doesn't crash if I Run inside the debugger.
If I attach the debugger to the process after starting it, it does not crash on exit.
I suspected a problem in finalization, so I put print statements in all the finalization code I suspected was running. This turned up nothing useful. Finalization for one of our low level Units (with no dependencies on any non-system Units) is running correctly. So it still could be finalization, but it may not be.
The crash produces this dialog:
Problem signature:
Problem Event Name: APPCRASH
Application Name: MCLTesting.exe
Application Version: 0.0.0.0
Application Timestamp: 4eb07b50
Fault Module Name: kernel32.dll
Fault Module Version: 6.0.6001.18215
Fault Module Timestamp: 49953395
Exception Code: c0000005
Exception Offset: 000bf395
OS Version: 6.0.6001.2.1.0.256.6
Locale ID: 3081
Additional Information 1: b37c
Additional Information 2: 2a7328d8bb40c81c93b4b5f46adb8e10
Additional Information 3: b37c
Additional Information 4: 2a7328d8bb40c81c93b4b5f46adb8e10
"Exception Code: c0000005" Does that mean anything?
The main clue I have is the fact that it doesn't crash in the debugger. Has anyone seen that before?
I finally tracked this down.
The problem was indeed in a finalizer. A user exception was being thrown in a finalizer. The exception was not caught, and the exception itself was being leaked (The Exception and its string were not freed). It seems this memory leak was causing the crash? I'm not sure why I didn't notice this memory leak when I originally posted.
Catching the exception fixed the crash problem.
One interesting thing I found out is that even if an uncaught exception is thrown in a finalizer, subsequent Unit's finalizers will still be run. I was assuming that a problem in one finalizer would stop all subsequent finalizers from running.
The method I used to find the offending Unit was very simple; I removed all units from my project, then reintroduced Units one by one until I got the crash bug. Time consuming but it worked in the end.
Exception code c0000005 is an access violation. This usually means one of two things: either you're attempting to dereference a pointer or object reference that's set to nil, or you're working with corrupted memory.
The other pertinent piece of data in the error report is Exception Offset: 000bf395. That tells you where the error is occurring. Try looking up f395 in your map file and see if you can't find a unit finalization that corresponds to that memory offset. If so, that should give you a good idea as to what's going wrong.