I'm using Firebase Crashlytics to get crash reports from my iOS app and I get some crashes that I don't understand with a <compiler-generated> error message. I don't understand what causes this kind of crash.
When I look at the stack trace I get one or several lines with the compiler-generated error message too.
I've been searching but can't find the reason or reasons why this kind of crash happens. In this particular example here is the function where the crash happens (it doesn't say which line). From what I see I can only guess that it has to do with the fact that I'm using an index from an array on another array so it might be out of range... but I don't really know.
It makes it really hard to fix crashes cause I just can assume what might be wrong in my code. Plus if the problem is actually the range out of index thing, shouldn't it report the line where the crashes occurs ? I'm really trying to understand the compiler-generated thing more than solving this actual crash :)
Compiler-generated means code injected into final binary by swift compiler. This might be unrolled inline-type library function, optimisation things, etc. The crash-log on your screenshot just shows the top call of the failed execution stack, and in majority of cases it is not your code line (while there is the reason) but some standard function call (from library or autogenerated). So you have to investigate not just one first line, but complete back trace of crashed stack.
Related
From time to time, Xcode Crashes comes up with a crash that i cannot understand. I pasted the xccrashpoint to gist
It states, that Thread 12 crashed somewhere in CoreGraphics called by CorePDF, called by QuartzCore drawing some layers. This seems like OS-called code, maybe via thread 1 which is doing _saveSnapshotWithName. So i assume, that this happens when closing the app.
Does anyone have at least a rough idea what is going on here? Maybe someone saw something similar before and can give a hint about what is crashing…
There is nothing special in the app that would cause dramatically wrong behaviour when leaving the app (-> when a screenshot ist taken).
Exec bad errors occur when an attempt is made to access a object or memory location which is not yet initialized.
There might be a problem with an object which you are not defining global.
Check if there is any object you defining and initializing in a method and trying to access out of the scope.
For more details related to errors and crashes, please go through below link.
http://www.raywenderlich.com/10209/my-app-crashed-now-what-part-1
In the age of Objective C, when I had error in my code and run it I received green thread breakpoint, but if I push button "Continue program execution" in the Debug Area, my app crashes and shows me exact error description.
Right now I'm suffer from "breakpoint loop" which occurs if I push continue button it stops at the same place and never crash. App doesn't crash at all and I haven't got any app error description. This is really annoying me, Thread 1: EXC_BREAKPOINT (code=EXC_ARM_BREAKPOINT, subcode=0xe7ffdefe) isn't very useful information in point of view of good old fatal error descriptions and so on.
Is there a way to break this "breakpoint loop" and crash the app to see error description?
EDIT:
Note: here I used word breakpoint, I didn't mean breakpoints that was set by myself, I meant default runtime crash breakpoints. Here is image of it (correct my if I named it wrong):
My breakpoint navigator:
The EXC_BREAKPOINT exception just means that the program tried to execute some particular "trap" instruction. That happens to be the instruction that debuggers use to set breakpoints. However, there are a number of system components that also use the trap instruction to halt execution when the program hits some exceptional condition. The idea being that if you are in the debugger, your app will stop and you can analyze the problem, but if not the app will die at that point.
You can tell whether the debugger is responsible for the trap because if lldb recognizes the EXC_BREAKPOINT as coming from a trap that it inserted, then it will tell you the stop reason was "breakpoint 1.1" or whatever - it won't show the raw EXC_BREAKPOINT as the stop reason. So if you are seeing EXC_BREAKPOINT it means you got some kind of internal assertion failure.
Usually you can tell what's going on by going to the bottom-most frame in the stack and looking at the code that has the trap inserted in it. Sometimes this isn't obvious in Xcode because if you stop for some exceptional reason in a stack where the bottom-most frames are assembly code, Xcode will select the lowest frame in the stack that has debug information. But if you look at the stack, you may see more frames below the stack.
You will also sometimes see little chunks of code that belong to your function, but come after the normal return instruction for you function. For instance, the stack guard mechanism will write a little error-handling section after some functions, and jump there and then trap if it notices stack overflow.
Am new to the iOS development. While looking into one of the App I work on, with exception breakpoint enabled in xcode. I see so many repetitive exceptions been raised.
But till now, we never realised this, as iOS was excusing those exceptions. The main exception was happening in our service layer, where, in an XML parsing, one of the element mentioned as key was missing. since so many back end requests are fired, for every XML response, and for multiple items inside it, this exception is thrown.
Now that our app is published, will this impact the device's stability? We are planning to fix thee kind of issues. But now, Will these be logged into Apple's diagnostic information. Just curious to know these. Can someone shed some light over it?
In Objective-C, Exceptions are used to signal fatal errors, that is programmer errors and "unexpected" and unrecoverable runtime errors. In Objective-C, Exceptions are a debugging and testing aid, not a construct to control program flow or to regain control after an error.
Usually, an application in a release state shouldn't throw exceptions. If it happens anyway, the only correct course of action is to terminate the program as soon as possible. In general, the Objective-C system frameworks are not exception safe. This means, after an exception has been thrown the application's state will be corrupt. If your program continues, even worse things may happen.
There are only a few, always undocumented harmless cases where exceptions will be thrown and caught by system libraries without leaving the program in an unstable condition.
See also https://developer.apple.com/library/ios/documentation/cocoa/conceptual/Exceptions/Exceptions.html
I'm working on an iPad application and a recent change I made is causing the app to die with "signal SIGTRAP". The stack trace doesn't help and I can't pinpoint what part of the code is causing this to happen (but I do know which function it starts from).
Without going into details about the application I was wondering if there are some general tips for debugging this kind of thing (SIGTRAP)?
I've managed to narrow down which function call causes this to happen. The weird thing is that if I break and step into the function then it works fine. But if I let it run without a breakpoint then it crashes.
The function calls a bunch of other things which also involve asynchronous network connections. I put logs all over my code and all my logs print fine, so it seems something "under the hood" is causing this failure. I'm also using a 3rd party framework which may be causing this issue?
Is this even a code-related issue? I read somewhere that SIGTRAP is a debugger thing.
What causes this kind of crash and where should I be focusing my efforts to fix it?
Any help you can provide is greatly appreciated.
Thanks!
Having a hard time tracking down a crash in an iPad application. The difficulty really stems from the fact that there is no errors or stack trace present when the application fails. It simply goes away like Keiser Soze, "And like that, poof. He's gone.".
I've replicated the crash on both the simulator and the device. There are zero device logs, nothing in the console, etc.
I know that during the crash some CoreGraphics operations are occurring in a background thread. Typically, three or so NSOperations are kicking of some image blends.
The blending consists of CGContext* calls (DrawImage, SetBlendMode, SetAlpha, etc). The NSOperation calls back to a delegate in the main thread to handle the image and set it to UIImage, so it shouldn't be a UI main thread conflict, but I'm not discounting anything at this point.
Are there some Xcode tricks I'm missing to track down exactly what is happening? Or at least get a better hint of where the problem lies?
EDIT I have run the app in Instruments tracking memory usage and see that it is pretty rock steady around 2MB. So, don't think it's a memory issue. But after consideration, this rock steady 2MB seems abnormally low. Is there a chance Instruments is not picking up the CoreGraphics allocations?
Try reading the registers.
Whenever my app crashes without error, in most cases I have found the exception in the registers.
First go to Exceptions tab and 'Add Exception Breakpoint' using the + at the bottom left corner.
Then when the app crashes click on "0 objc_exception_throw" under Thread 1
Finally in the console enter:
register read
(you should get a list of registers)
po $rax (normally the exception is in 'rax')
(you should see the exception output on the console)
Hope this helps.
For lack of a better solution, and if it isn't obvious, pepper your app with NSLogs to circle where this occurs, then drill deeper from there via breakpoints and/or additional logs.
Super late answer, but I've found that using try/catch helps give information when I can't get a stack trace and my application pulls a Keiser Soze.
#try
{
// suspected code causing crash/errors
}
#catch (NSException *exception)
{
NSLog(#"Exception: %#", exception);
}
In my case, it was because of bad outlet connection in the storyboard.
Check using breakpoint if viewDidLoad method of UIViewController to be loaded gets called. If not, check your outlet connections in the storyboard.
Incorrect connection crashes the app without any error or stack trace.
I am wondering what happened to the this class is not key value coding-compliant for the key error that used to show in older versions of XCode.
In my case, it was because I had "Zombie Objects" enabled in the scheme to help find the problem, which was eventually causing it to run out of memory and crash.
In my case it was due to an object being released. Normally it would say message sent to deallocated instance or something like that, but it didn't. I checked the iPhone's logs and found this: KERN_INVALID_ADDRESS, which I googled and came across this: KERN_INVALID_ADDRESS
Enabled zombie objects and found that I tried to use a deallocated instance. It also told me what object it was in the logs afterwards.
Hope it helps for future visitors.