Using raygun4ios in iOS 8 crashes

desiltc

Posted on
Oct 05 2014

We are moving our codebase from Xcode 5 to Xcode 6 as part of the shift to the newer platform Apple is offering. This is in conjunction with supporting iOS 8 for our App.

Raygun4ios was working and reporting errors to Raygun.

After the move to iOS 8, raygun4ios causes the app to crash when an error is attempted to send to raygun using: [[Raygun sharedReporter] send:exception];

We have installed the latest build of raygun4ios.

Please help.

Thank you

Jason Fauchelle

Raygun

Posted on
Oct 17 2014

Hello,

We have looked into this extensively, and was finally able to reproduce this problem, but only when using Raygun4iOS v1.4.0. We can confirm that version 1.4.1 is working correctly in iOS 8.0.

If you have ever used version 1.4.0, is it possible that this old version is still hanging around in your machine and your application is using it? Possibly from within a build folder. Please try uninstall the application from the device or simulator, then delete the appropriate folder in the XCode/DerivedData folder, then clean, rebuild and rerun the application.

If the problem remains, let us know if you are calling the identify method on the shared raygun reporter any time before calling the manual send method. It would also be really helpful to see code snippets of how/where you are setting up Raygun4iOS, how/where you are performing the manual send, and where does the exception object come from?

-Jason Fauchelle

Dan Too

Posted on
Oct 30 2014

Hey Jason,

I still have lots of these crashes on iOS8 also, using the 1.4.1 cocoapod.

For instance:

Assertion failed: (writer->uncaughtexception.hasexception == false), function plcrashlogwritersetexception, file /Users/martin/Development/raygun4ios/src/Private API/Crash Log Writer/PLCrashLogWriter.m, line 479.

-Dan

Jason Fauchelle

Raygun

Posted on
Oct 30 2014

Hi Dan,

Thanks for mentioning this. The exception you've posted is different to the original issue of this thread. Interesting that you point this out though. I've recently started seeing this problem too when exploring Raygun support in Swift applications. I get the same error that you posted when running in the emulator, but when running on a device it works fine. Is this the same behaviour for you? Are you seeing this error in a Swift app or a pure Objective-c app?

I will be looking into this issue further soon.

-Jason Fauchelle

Dan Too

Posted on
Oct 30 2014

This app is pure Obj-C, and crashes reliably for me at the moment.

My latest crash says: uncaughtexceptionhandler at PLCrashReporter.m:360: 0x10b366945: pushq %rbp 0x10b366946: movq %rsp, %rbp 0x10b366949: movq %rdi, %rax 0x10b36694c: leaq 0x9a0f5(%rip), %rdi ; signalhandlercontext 0x10b366953: movq %rax, %rsi 0x10b366956: callq 0x10b373d7f ; plcrashlogwritersetexception at PLCrashLogWriter.m:478 0x10b36695b: callq 0x10b37a74a ; symbol stub for: abort

Jason Fauchelle

Raygun

Posted on
Nov 03 2014

Thanks Dan,

I have reproduced this issue and found a solution. We'll release a new version of this soon and I'll get back to you when this is available.

-Jason Fauchelle

Jason Fauchelle

Raygun

Posted on
Nov 07 2014

Hello,

We have resolved all issues with using Raygun4iOS in an iOS 8.x application. These issues are resolved in the latest version of Raygun4iOS (1.4.2) which is available in CocoaPods or from the direct download here: https://raygun.io/raygun-providers/ios

-Jason Fauchelle

Dan Too

Posted on
Dec 12 2014

Hey Jason,

Sorry to bring up an old thread, but I found a simple reproducible way to demonstrate one of these crashes in the iOS Simulator. I've made a sample project for you to clone - hopefully you guys can try this out and fix

https://github.com/regennz/raygunCrash

Cheers Dan.

Jason Fauchelle

Raygun

Posted on
Dec 15 2014

Hello Dan,

Thanks for sending the project. Unfortunately your demo project is exhibiting the expected behaviour. Here's why:

When Raygun4iOS is integrated into a project, and then the application crashes, the error message is not sent to Raygun instantly. This is because when the app has crashed, the state of the memory is in an unpredictable state, and so it would be unsafe to attempt a send. Instead, Raygun4iOS will first save the report to the device/emulator, and then allow the app to continue shutting down. Saving the report to the device is safe due to very carefully crafted code in the PLCrashReporter framework at the core of Raygun4iOS. Once the app starts up again, any saved reports can then be safely sent to Raygun.

Your demo application is crashing as soon as it starts. If you do this in the simulator, you will be able to see that Raygun4iOS is successfully detecting the crash and saving the report. -You can find a file called livereport.plcrash in Library/Developer/CoreSimulator/Devices/{SIMULATORID}/data/Containers/Data/Application/{APPLICATION_ID}/ Library/Caches/com.plausablelabs.crashreporter.data/nz.regen.RaygunTest

Note: This file will probably only be created if the app crashes when the XCode debugger is not attached to the app (The XCode debugger likes to stop program execution at crash points). Also, to find the above address in Finder, you may need your Mac set to display hidden files and folders.

So, it's great that the crash report is written, but the problem lies in the next step: Raygun4iOS will detect this report and attempt to send it to Raygun when you run the app again. But unfortunately as your demo app crashes as soon as it starts and shuts down the process, there is absolutely no time for Raygun4iOS to complete the send. (This is what is happening on both the device and simulator).

If you cause your demo app to crash (using the same crash code) via the result of a user action - such as pressing a button, then you will find that the error report can be sent to Raygun.

In a published app, it is unlikely that an app will crash as soon as it starts, as that will fail App Store submissions - and there shouldn't be anything that changes later to cause the published app to start crashing on every startup.

I will look at documenting this scenario.

Please let me know if you have further questions.

-Jason Fauchelle

Dan Too

Posted on
Dec 15 2014

Hey Jason,

Interestingly, if I change that crash to the following (i.e. the same but delayed by 5 seconds):

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5*NSEC_PER_SEC), dispatch_get_main_queue(), ^{
    // lets crash something!
    NSString *testObject = nil;        
    NSDictionary *testDictionary = @{@"test": testObject};
});

it still has the exact same issue. Any thoughts on why?

Jason Fauchelle

Raygun

Posted on
Dec 15 2014

Thanks for the code snippet! I'd never tried this before.

This is working fine at my end. Some gotchas: Make sure to delete the app from the device/simulator as otherwise I often find that changes don't get deployed. Performing a Clean on the app in XCode before re-deploying as well may help too. Also, make sure the XCode debugger is not attached to the app as I mentioned before. If the debugger is attached, just let the app crash, and then run it again directly in the device/simulator. Let the app crash again to generate the report, then run the app once more to send it.

Hope that helps you get this test scenario working!

-Jason Fauchelle

Dan Too

Posted on
Dec 15 2014

This sample will definitely crash for me with a RaygunTest`uncaughtexceptionhandler at PLCrashReporter.m:360: when debugging in the simulator (with the debugger attached).

Is there no way I can debug a crash while the raygun library is active then? Sounds like I'd need to remove the raygun stuff while I'm working on features, then enable it again for production

Jason Fauchelle

Raygun

Posted on
Dec 15 2014

This will depend on the kind of error you are debugging. For some reason, the crash you are replicating in the test app (and at least one other type of crash) seems to be missed by the XCode debugger. If I disable Raygun4iOS, the XCode debugger is then showing me that a crash has occurred at main.m - and that's it - which also is not useful. Is this also the behaviour that you see in your app if you disable Raygun4iOS?

On the other hand, there are many other types of crashes that the XCode debugger does land on - whether Raygun4iOS is enabled or not.

The abort statement in PLCrashReporter.m:360 is to trigger the crash handler and cause a normal exception dump. This happens after your crash occurs in ViewController.

I'm not sure there if any change we can make in Raygun4iOS that will get the XCode debugger working correctly in this scenario.

-Jason Fauchelle

Dan Too

Posted on
Dec 17 2014

My xcode debugger does pick this one up properly, so I'm not sure why we're seeing different things.

Jason Fauchelle

Raygun

Posted on
Dec 17 2014

Just to clarify, are you using XCode 6? In any case, we would recommend that you disable Raygun when working locally, but enable it locally in times that you really need it. You could use a compiler directive to only enable Raygun4iOS when not in debug mode for example. Raygun is most valuable within published applications.

Reply