Raygun supports a wide range of languages and platforms, one of which is Xamarin for iOS that allows developers to build iOS applications using .NET. By integrating the Raygun4Net provider into your Xamarin.iOS applications, exception details are sent to your Raygun dashboard if your application crashes while a customer is using it. Most of the time these will be .NET exceptions, but in some situations an exception may occur in the native Objective-C core of the application resulting in an NSException being thrown. Xamarin wraps these up in a MonoTouchException which Raygun will happily catch and send to your dashboard. This is great, but the stack trace from this type of exception is nothing to look at:
MonoTouch.UIKit.UIApplication.Main(String args, String principalClassName, String delegateClassName) in /Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:38 Xamarin_iOS_ErrorHarness.Application.Main(String args) in /Users/mindscape/Projects/Xamarin_iOS_ErrorHarness/Xamarin_iOS_ErrorHarness/Main.cs:27
All you get is a message saying that the exception started from Main.cs, not where the exception actually occurred. Not the worlds most helpful stack trace!
We have recently updated the Raygun Xamarin.iOS support for this scenario to send the native Objective-C stack trace instead which can provide much more insight as to what the problem is.
[NSInvalidArgumentException: -[NSObject rubbish]: unrecognized selector sent to instance 0x11ee0c60] 0 CoreFoundation 0x016005e4 __exceptionPreprocess + 180 1 libobjc.A.dylib 0x04e748b6 objc_exception_throw + 44 2 CoreFoundation 0x0169d903 -[NSObject(NSObject) doesNotRecognizeSelector:] + 275 3 CoreFoundation 0x015f090b ___forwarding___ + 1019 4 CoreFoundation 0x015f04ee _CF_forwarding_prep_0 + 14 5 Foundation 0x01cc936c __NSFireDelayedPerform + 372 6 CoreFoundation 0x015bec46 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22 7 CoreFoundation 0x015be62d __CFRunLoopDoTimer + 1181 8 CoreFoundation 0x015a6698 __CFRunLoopRun + 1816 9 CoreFoundation 0x015a5b33 CFRunLoopRunSpecific + 467 10 CoreFoundation 0x015a594b CFRunLoopRunInMode + 123 11 GraphicsServices 0x060319d7 GSEventRunModal + 192 12 GraphicsServices 0x060317fe GSEventRun + 104 13 UIKit 0x0293794b UIApplicationMain + 1225 14 ??? 0x11fa153c 0x0 + 301602108 15 ??? 0x11fa046c 0x0 + 301597804 16 ??? 0x11f9ee70 0x0 + 301592176 17 ??? 0x11f9ef17 0x0 + 301592343 18 Xamarin_iOS_ErrorHarness 0x000e7f26 mono_jit_runtime_invoke + 790 19 Xamarin_iOS_ErrorHarness 0x001821ef mono_runtime_invoke + 127 20 Xamarin_iOS_ErrorHarness 0x00187a63 mono_runtime_exec_main + 435 21 Xamarin_iOS_ErrorHarness 0x00187804 mono_runtime_run_main + 628 22 Xamarin_iOS_ErrorHarness 0x0005511d mono_jit_exec + 93 23 Xamarin_iOS_ErrorHarness 0x0021e91a main + 2426 24 Xamarin_iOS_ErrorHarness 0x000077d5 start + 53
The first line displayed in the previous code block is the exception message. Some of the error grouping takes into account the message which can result in a group being made too frequently for what is essentially the same exception. For NSException messages such as the one displayed above (which I’ve displayed again below), you’ll see there is a memory address displayed at the end.
unrecognized selector sent to instance 0x11ee0c60
This address is always different, even if 2 exceptions occurred in the same point of code. We have of course taken this into consideration with the Raygun grouping logic. For NSException messages, the memory address will be ignored so that messages that come from the same exception will be grouped together in your dashboard. This is so we provide first class app support for NSExceptions.
These improvements to the Xamarin.iOS support are available right now! Make sure to integrate the latest provider into your application so that you can log better stack traces for these types of exceptions. Look for version 1.0.12 or higher on GitHub, NuGet or the Xamarin Component Store.