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).
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've set an "All Exceptions" exception breakpoint for my project. In Xcode 7, it mysteriously fires on launch in main.m, but there doesn't seem to be anything obviously wrong. On continuing, the app runs normally.
Even running the project in Xcode 6 now causes this breakpoint to fire.
I can't figure out what is causing this. The threads don't indicate anything specific to what the cause is.
Maybe it's some sort of font issue in the Storyboard or something? Does anyone know a fix?
NOTE: It's a C++ exception, not Objective-C. Perhaps due to missing fonts. Xcode throws an exception in Main() in iOS 8 with 'all exceptions' breakpoint
I have almost the identical problem in Xcode 7, as of beta 3. This workaround solved it for me.
Because it's a C++ exception, you can change your "All Exceptions" breakpoint to catch only Objective-C exceptions. Having done this, I no longer hit the mystery break on startup, and because I'm not writing C++, get 99% of the value of having the "All Exceptions" break point on.
Here's how:
Go to the breakpoints tab (View > Navigators > Show Breakpoint Navigator or ⌘7).
Right click on the All Exceptions breakpoint and "Edit Breakpoint..."
Change the Exceptions covered to Objective-C only.
I started seeing the same behaviour in my application using the shorthand dictionary initialisation #{ ...: ... } in the willFinishLaunchingWithOptions function.
The problem was solved by replacing it with dictionaryWithObjectsAndKeys instead. I'm not sure if this was specific to my case or if the compiler has some kind of a problem with the shorthand syntax, but it's worth checking out if you're using that syntax.
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
Why do I have this following break point be triggered every time when I launch my application?
I added "All Exceptions" break point in my project, but I don't know what kind of exception is this. The app can keep running if I skip this break, however when running in the device, there's a crash happened couple times due to the same call stack.
Your crash is occurring during global / static initialisation. You've probably got some unsafe code tied to the initialisation of a global variable, but it's hard to say without more context.
If you're seeing this crash on iOS9 (beta 3), it may e related to one of the libraries you're using. If you're using Cocoapods, try to remove them one by one, until you find the responsible one.
In my case, the crash was caused by the ArcGIS SDK: https://github.com/bamse16/TestEsriiOS9
Xcode 5.1 no longer officially supports GDB, instead defaulting only to LLDB. The problem with LLDB is that it shows no useful debug information on app crashes. Furthermore, all Exception Breakpoints simply break on main.m. This makes debugging ridiculously tedious. I read here on SO that this is a common problem with LLDB and that GDB does a better job.
How do I enable GDB for xcode 5.1?
There is no way to use gdb with more recent Xcodes.
I don't know what you mean by "it shows no useful debug information on app crashes." Probably best to file a bug with bugreporter.apple.com with some more detail, there may be a way to get lldb to work correctly for you.
I am also not sure what you are seeing when you say "all Exception Breakpoints break on main.m". If you go to the lldb console and do:
(lldb) break list
are the breakpoints actually on main.m?
One thing to be a little careful about with the Xcode 5 Debugging UI (maybe this started with 4, I can't remember.) When your program stops due to a crash or exception in a stack frame that starts with frames that have no debug information, Xcode will actually select the first frame up the stack that has debug information. This is to avoid showing people screens full of disassembly, which some folks find frightening... So the source frame will show, say, main.m, though the actual bottom-most frame is something else.
Xcode also has a "stack compression" feature that will hide "uninteresting" frames. That can also make this kind of stop confusing - though it will generally show the bottom-most frame you might miss that and only see your source frame. The stack compression can be turned off if you don't like it.
Make sure that is not what you are seeing.