My code crashed, and the following line gets highlighted in red. But some crash handle function should continue. How can i debug this crash handle function:
NSSetUncaughtExceptionHandler(&HandleException);
The error that you're generating doesn't result in an Objective-C exception, so exception handlers aren't going to be invoked for it.
If you're trying to test exception handling, you should replace your method code with a throw. If you're trying to test for handling of that specific code, you should create a signal handler for the error that's cut off by your screen shot. (SIGABRT, SIGSEGV, ...?)
Related
I've hit an assertion in code and wondering if there's a way to create a wrapper around the assert that would enable breaking out and continuing execution or some other function that would enable a way to suppress the assert through the lldb debugger.
assert(condition(), makeCriticalEvent().event.description, file: fileID, line: UInt(line))
This is the standard assertion in apples libraries here. When I hit this assertion I tried continuing execution but it stays stuck at the assertion. I'd like to silence the assertion (likely through the lldb debugger by typing some command). Anyone have an idea how to do this?
You have to do two things. First, you have to tell lldb to suppress the SIGABRT signal that the assert delivers. Do this by running:
(lldb) process handle SIGABRT -p 0
in lldb. Normally SIGABRT is not maskable, so I was a little surprised this worked. Maybe because this is a SIGABRT the process sends itself? I don't think there's any guarantee suppressing SIGABRT's has to work in the debugger so YMMV, but it seems to currently. Anyway, do this when you've hit the assert.
Then you need to forcibly unwind the assert part of the stack. You can do that using thread return, which returns to the thread above the currently selected one w/o executing the code in that frame or any of the others below it. So just select the frame that caused the assert, go down one frame on the stacks and do thread return.
Now when you continue you won't hit the abort and you'll be back in your code.
I'm using the library called CwlPreconditionTesting which is used to test Swift assertions. It uses Mach exceptions handler API to catch exceptions that's available on iOS and OS X.
The library works well in simulators, but devices aren't supported by it. The reason for this is that on devices, the Swift assert functions (e.g. fatalError) crash with EXC_BREAKPOINT exception type, which is also the exception type the debugger uses when someone puts a breakpoint somewhere and the debugger wants to suspend the program. The underlying assembly instruction is brk.
I wanted to add device tests support to the library, but after setting up the exception handler, if the debugger reaches a breakpoint I added manually, the debugger just hangs. To bypass this, I tried to make the exception handler forward the handling of the exception to the debugger.
When I implement an exception handler, if it returns with a failure (i.e. anything other than KERN_SUCCESS), the kernel should forward it to the next exception handler in line, the debugger in my case. I didn't find any official documentation on this, but it says so here and in a piece of code from Mike Ash's blog:
// Handle EXCEPTION_DEFAULT behavior
kern_return_t catch_mach_exception_raise (mach_port_t exception_port,
mach_port_t thread,
mach_port_t task,
exception_type_t exception,
mach_exception_data_t code,
mach_msg_type_number_t codeCnt)
{
// Do smart stuff here.
fprintf(stderr, "My exception handler was called by exception_raise()\n");
// Inform the kernel that we haven't handled the exception, and the
// next handler should be called.
return KERN_FAILURE;
}
Even if I always return KERN_FAILURE, the debugger hangs when I pause at a breakpoint. Here's a screenshot from the Variables View in Xcode, which loads indefinitely:
Is there a way to set up an exception handler and live in peace with LLDB?
I have an iOS application written in Swift 2 in Xcode 8.2.1, that's built for iOS 10.2.
I've had a number of crash reports from TestFlight and despite symbolication, none of the crash logs show any program state besides the stack-traces (no argument values, no locals, no heap objects, etc).
...but inside those functions I can see code which is likely to fail (e.g. a forced unwrap) but the crash log isn't telling me where or why it's failing.
When debugging in Xcode, I can use fatalError(message: String) where I can put my own message like "functionFoo returned nil" or "variable bar == \"" + bar + "\"", except when deployed using TestFlight or the App Store the fatalError will be hit and the program terminates, but the message value is not saved to the crash log, making it pointless.
In other environments, like C#/.NET and Java I can simply throw new SomeExceptionType("my message") and all information is available in whatever global catch(Exception) handler I have.
How can I achieve the same goal in iOS / Swift?
Swift does support error handling. You can create your own error type by confirming to Error protocol or use existing error types and then throw an error by invoking throw error.
But Swift forces you add error handling to any code that can throw an error. There are multiple way you can handle error in swift.
Apply throws keyword to your function, this indicates that the function can throw an error when invoked and the error should be handled by the caller.
func canThrowErrors() throws -> String
When invoking methods with throws keyword you have to add try keyword at the beginning of the invocation. All these try invocations should be handled either by applying throws to method to just propagate the errors or wrapping inside a do-catch block:
do {
try canThrowErrors()
try canThrowOtherErrors()
} catch is SpecificError {
// handling only specific error type
} catch let error as SpecificError {
// catches only specific error for type
} catch {
// catches all errors
}
Additionally you can use try? and try! for throwing function invocation to disable error propagation and retrieve optional result that returns nil in case of error and runtime assertions respectively.
By forcing you to handle all the errors at compile time swift avoids any undefined runtime behavior and debugging nightmare.
I would suggest to use fatalError or any other runtime assertion only if scenarios when there is no way to recover from a state without crashing the app. Unfortunately, there is no way to handle errors from fatalError as its use is only reserved for such scenarios only. Also, in your crashlog you will only get the line number that caused the crash to get additional info for the cause of crash I would suggest to use custom logging or analytics.
Using XCTest, a test does the following:
XCTAssertThrowsSpecificNamed([does something that breaks], NSException, NSInvalidArgumentException);
I don't want the debugger to stop on the NSException that I know will occur but I want it to still stop on other exceptions that might occur.
Basically we don't have a choice. I still consider it an xCode bug because you already told xCode an exception will be thrown, and what exception it will be. Why provide XCTAssertThrows if it's an exception you're not "expecting"?
Obviously it's for exceptions you are expecting, which #nhgrif argues should be an error, not an exception. Might be a good point, but i do want my program to crash if this case ever happens, because I can't handle it.
So the real question is more why not disable the debugger on that exception only? Probably because they haven't gotten around to it. I'd suggest opening a bug/feature request with Apple. I'd love for someone to contradict me on this (please comment!) but until then, I'll live with this issue (disable debugger when running all my tests).
--> https://stackoverflow.com/a/22393643/1701430
"Why does the test stop when the execution is thrown?"
Because you have a breakpoint, which stops execution.
"Why, after removing the breakpoint, does my application crash when the exception is thrown?"
Because you have an unhandled exception. Unhandled exceptions cause your program to crash.
"How can I handle an exception so it won't crash my program?"
The easy answer to this question is to simply NOT throw an exception. In other programming languages, like Java, this is perfectly standard. But in Objective-C, we don't really do exceptions. In Objective-C, exceptions should be saved for TRULY exceptional behavior.
With that said, and a strong suggestion for you to find another way to handle whatever it is you're trying to handle, this is how you handle an exception in Objective-C:
#try {
// code that could throw an exception
}
#catch (NSException *e) {
// handle the exception...
}
#finally {
// post try-catch code, executed every time
}
SUMMARY
When I set an exception breakpoint, I don't get the exception message. How do I get the exception message? I already know how to get the stack trace, but that doesn't include the exception message.
DETAILS
In the past I developed iOS Apps with Xcode and when there was a problem, I'd get an error/exception. The exception would often have a message like "can't dereference null" or whatever.
Now, using Xcode 4.6.x for the past several weeks I've never gotten an exception message. I'll often get a SIGABRT. I put in the break on exception breakpoint and it will break there, but it's off in some assembly within the iOS SDK and I never get a message.
In fact, I can't remember the last time I saw anything show up in the debugger console.
Did exception info dissappear with the migration to LLVM?
It's very frustrating to have my app just crash in the SDK without knowing why. I check the last function to make sure things are set up correctly (objects allocated, etc) and they are which means I'm left with no clues.
Is it possibly a build setting held over from the past is somehow turning off exception messages?
Please reopen question. It now has an answer!
In the comments an excellent answer has been given. This should be promoted to full answer, and so I can mark the question answered and others who have this common issue can find it. In order for that to happen, the question needs to be reopened! (I'll delete this plea after that happens.)
I will update Jeff's answer here:
To have both the line causing the exception highlighted (and not UIApplicationMain() in main.m) AND to see the reason for the exception (e.g., "error: A fetch request must have an entity."), do this:
In the Breakpoint navigator:
Add (+), Add Exception Breakpoint
Select the new breakpoint, Control-Click, Edit Breakpoint
Add Action
Enter: po $arg1
The relevant part of the stack trace will be in the nagivator area.
This seems to still work in Xcode 9
Here is my addition for use with Xcode 6 and below.
Enter: po (NSException*) $eax
In Xcode 6 you must explicitly provide the object type because it is no longer inferred.
For Xcode 7-9 (based off Jeff's answer):
In the Breakpoint navigator:
Add (+), Add Exception Breakpoint
Select the new breakpoint, Control-Click, Edit Breakpoint
Add Action
Enter: po $arg1
To have both the line causing the exception highlighted (and not UIApplicationMain() in main.m) AND to see the reason for the exception (e.g., "error: A fetch request must have an entity."), do this:
In the Breakpoint navigator:
Add (+), Add Exception Breakpoint
Select the new breakpoint, Contorl-Click, Edit Breakpoint
Add Action
Enter: po $eax
The relevant part of the stack trace will be in the nagivator area.
Yes xcode is not so friendly for debugging. I like this article which helps me to understand crash logs a bit clearly))
Demystifying iOS Application Crash Logs
Also do this if you see error "message sent to deallocated instance"
'Products -> Edit Scheme -> Enable Zombie Objects'
this will enable zombie objects and when you do profile to your project choose
"zombie", cause error and you will be able to see which objects was deallocated e.g NSArray *myArray
The information I get from po $eax or po (NSException *)$eax seems to be different from what Xcode would print if no exception breakpoints are set. So I do the following,
Add an exception breakpoint
Exception occurs, breakpoint was hit -> I know the location
Temporarily disable breakpoints (second button on the left in Debug area)
Continue program execution (third button on the left in Debug area)
Details are printed -> I know the cause
Obviously not very elegant and flexible, but at least I two big questions are answered (where and why).
You can use bt or thread backtrace command to print error trace
Show the stack backtrace for the current thread.
The same stack trace you can find in crash reports
Information about current thread use currentThread
//Objective-C
po [NSThread currentThread]
//Swift
po Thread.currentThread
*Sometimes you can use fr v(or just v from XCode 10.2) when po is not working