Xamarin.iOS Crashing when SIGSEGV catching enabled

Hello,

Thanks for pointing this out. I have not been able to reproduce this yet but will keep trying tomorrow. If you are able to send a simple repro project, that would be a huge help to debugging this. In any case, I'll let you know what I find tomorrow.

-Jason Fauchelle

Hello,

I have had another extensive look into this, but have not yet been able to reproduce this issue. The answers to these questions will help me look into this further:

Are you throwing or causing an exceptions on app startup (either in managed or native code)?

If you change both parameters in the RaygunClient.Attach call to true, does that solve the problem?

If you create a fresh new app and integrate Raygun4Net in the same way as you are doing in your app, does the problem still occur?

-Jason Fauchelle

Hello,

Thanks for all this additional information.

The only way the PLCrashReporter should be walking the stack frames is if a native error has occurred (This can include errors occurring in the native code that Xamarin generates from your managed code). Just to clarify (true, true) is working in your apps, but (true, false) is not? This most likely means that you have a NullReferenceException occurring within a try catch block somewhere in your code.

In mono, null reference exceptions start out as SIGSEGV signals in native code which in Objective-C is bad, and so PLCrashReporter detects this, reports it, and aborts the app before the try/catch in the managed code can do anything about it. That is the reason for the second parameter - when true, Raygun hijacks the SIGSEGV and SIGBUS signals to workaround the null reference within try/catch issue, but prevents native SIGSEGV and SIGBUS signals from being reported altogether.

The next step would be to look through any try/catch blocks in your apps to determine if this really is the case. If so, null reference exceptions are generally very easy to avoid with a null check, so I recommend fixing them where possible.

As for your other app with the login screen, I'm not sure what could be causing that, but would again recommend look at managed exceptions occurring in try/catch blocks. Does (true, true) fix the issue in your other app?

Hope that helps you look further into the issue. Let me know how it goes.

-Jason Fauchelle

Some excellent questions.

Null reference exceptions occurring outside try/catch blocks do in fact have the same effect - PLCrashReporter picks up the native SIGSEGV signal, reports it, and then aborts the app. That said, (true,true) would mean that the managed null reference exception gets reported which you would know about, so this shouldn't be related to your case.

If you are seeing native exceptions showing up in your Raygun dashboard, you can upload the dSYM that Xamarin generates when you build the app which will be able to symbolicate the stack trace to help with debugging. Line numbers will probably be off for any managed stack frames though. dSYMs will be generated for iPhone builds (not simulator builds) and can be found in the bin folder of your project. You can upload to Ragun by clicking Application Settings -> dSYM Center in the left-hand sidebar of your Raygun application. To symbolicate the stack trace, the dSYM will need to be generated from the same build that you report the error from. Note that these steps are only applicable if you are seeing native errors in your Raygun dashboard.

Both the PLCrashReporter and managed exception handler needs to be attached to get the most wide spread exception handling coverage. I have noted down to have a look at resolving the null native signal issue, but not sure when I can look into it yet.

Who is causing this issue can't easily be answered until I'm able to fully reproduce this at my end which is what I'll need to do in order to continue looking into this. If you can, please try to create a repro project that can demonstrate this issue. You mentioned that you tried Raygun in a new empty app, so you could use that project as a starting point. Perhaps comment out bits of you application to try and narrow down where the issue could be originating from. My next best guess is that a stack overflow exception is occurring in native code - this is something that PLCrashReporter doesn't detect, so that may be the next thing to search for. Since you have two apps with the same issue, try look into the similarities between them.

Also, in case you haven't done so already, make sure your using the latest stable build of Xamarin Studio and Xamarin.iOS

I hope we can get to the bottom of this. Let me know any further questions, information or observations you find.

-Jason Fauchelle