Common C# Exceptions Aggregated - NullReferenceException
jonathanpeppers
Posted on
Jun 05 2014
We're using the Xamarin component for reporting errors in a cross platform Android/iOS app.
One thing I keep seeing is that any NullReferenceException gets aggregated together, even though they could be completely separate issues. So the thing that further complicates it, is that I generally associate it with a Github issue, but we really need each occurrence (with a different stacktrace) associated with a different Github issue.
Is there a way to workaround this issue?
Thanks.
Jason Fauchelle
Raygun
Posted on
Oct 28 2014
Hi Jonathan,
Apologies for not replying to this earlier. The grouping logic does look at the stack trace to determine which error reports are generated from the same bug. Your Raygun application may have been using an older version of the grouping logic that only uses the message. Is this still an issue? If so, please let us know which of your Raygun applications has this issue and we could make sure it is on the latest version of the grouping logic. (Note however that doing this will cause all new exceptions to be added to new groups, rather than the existing groups on your Raygun account).
-Jason Fauchelle
jonathanpeppers
Posted on
Oct 29 2014
Hi Jason,
Not having issues with NullReferenceExceptions any more, thanks.
I am having issues with certain kinds of Obj-C errors not getting grouped in Xamarin apps. For example, in the Hanx Writer app:
Here are two examples of errors that are not getting merged into a single error group:
- https://app.raygun.io/dashboard/7f2j2x/errors/531251394?
- https://app.raygun.io/dashboard/7f2j2x/errors/531256755?
The error reads:
[NSInvalidArgumentException: Application tried to present inside popover with transition style other than UIModalTransitionStyleCoverVertical <_UIDocumentActivityViewController: 0x160a6e50>.]
0 CoreFoundation 0x23794e57 <redacted> + 150
1 libobjc.A.dylib 0x31109c8b objc_exception_throw + 38
2 UIKit 0x26f150b7 <redacted> + 5562
3 UIKit 0x26f154ab <redacted> + 258
4 UIKit 0x26d12243 <redacted> + 194
5 UIKit 0x2727ac4b <redacted> + 126
6 UIKit 0x26e36fb9 <redacted> + 740
7 libdispatch.dylib 0x316698cb <redacted> + 10
8 libdispatch.dylib 0x316698b7 <redacted> + 22
9 libdispatch.dylib 0x3166d0bf _dispatch_main_queue_callback_4CF + 722
10 CoreFoundation 0x2375abe9 <redacted> + 8
11 CoreFoundation 0x237592e9 <redacted> + 1512
12 CoreFoundation 0x236a7621 CFRunLoopRunSpecific + 476
13 CoreFoundation 0x236a7433 CFRunLoopRunInMode + 106
14 GraphicsServices 0x2a9ec0a9 GSEventRunModal + 136
15 UIKit 0x26c91809 UIApplicationMain + 1440
16 HanxiOS 0x001006b4 HanxiOS + 919220
17 HanxiOS 0x000ba720 HanxiOS + 632608
18 HanxiOS 0x00026074 HanxiOS + 24692
19 HanxiOS 0x00270740 HanxiOS + 2426688
20 HanxiOS 0x0055864d HanxiOS + 5473869
21 HanxiOS 0x005967a5 HanxiOS + 5728165
22 HanxiOS 0x0059a3fb HanxiOS + 5743611
23 HanxiOS 0x0059a23b HanxiOS + 5743163
24 HanxiOS 0x005465cd HanxiOS + 5400013
25 HanxiOS 0x005eb77c monotouch_IntPtr_objc_msgSend_IntPtr + 3808
26 libdyld.dylib 0x31689aaf <redacted> + 2
The only difference is the memory address in the message, which seems to keep them from grouping.
I also notice that these are not getting symbolicated, but I have uploaded the dSym files for each app store build and most TestFlight beta builds.
Do I need to delete old dSym files associated with the app? Or is something going wrong there?
Thanks,
Jason Fauchelle
Raygun
Posted on
Oct 29 2014
Hi Jonathan,
Thanks for pointing out the grouping issue. Currently we only strip memory addresses for Xamarin.iOS exceptions if they occur at the end of the message. I will look at improving this soon.
As for dSYM support, exception reports can only be symbolified if they were sent from native code. The exception you posted is actually a managed exception, but has a native-looking stack trace. This stack trace isn't actually enough to by symbolified against a dSYM. However, not long ago we released a beta version of an updated Xamarin.iOS provider which is able to detect and report native exceptions that previously could not be sent, and provide all the information that can be used to symbolify it with a dSYM. Also, enabling native exception reporting will cause the exception you posted to be sent in native code, rather than managed code. You can download it and read more about it here. Also, let me know if you have any questions about it. https://raygun.io/blog/2014/10/report-native-ios-errors-new-beta-xamarin-provider/
You don't need to delete old dSYMs for it to work, but you may want to delete old dSYMs that you no longer need.
-Jason Fauchelle
jonathanpeppers
Posted on
Oct 30 2014
Ok, so I'd love to use this beta in the Hanx Writer, but I am having to use the new unified Xamarin APIs. So I can't use this DLL. Is the source for it on a branch somewhere?
Eventually it would be great if you guys supported the unified API with your NuGet package, too -- it wouldn't take that long to do. I've ported the main iOS project to unified on this fork, but it needs to be setup as two projects and added to the NuGet package properly: https://github.com/jonathanpeppers/raygun4net
Jason Fauchelle
Raygun
Posted on
Oct 30 2014
Hi Jonathan
Thanks for mentioning this. We certainly plan to include a unified API version of the Xamarin iOS provider. It will be a couple of weeks before we can do this. For now, here is the branch that you can use to create a unified API version for your Hanx Writer app. https://github.com/MindscapeHQ/raygun4net/tree/bind-raygun4ios Let me know if you have any questions! We'd love to hear any feedback you have about it.
-Jason Fauchelle
jonathanpeppers
Posted on
Oct 31 2014
Yeah, since your new library is using a binding project, you can't build a unified binding project on the version of Xamarin.iOS that is out right now.
I emailed Xamarin to see if I can get an early build of this to try it out.
Jason Fauchelle
Raygun
Posted on
Feb 16 2015
Hi Jonathan,
Finally this is all supported now. The latest version of Raygun4Net includes support for reporting native iOS errors. This functionality is available in both the classic and Unified API versions that we provide. This is all available in both NuGet and the Xamarin Component Store. Here is a post with more information, and instructions to enable it: https://raygun.io/blog/2015/01/raygun-for-xamarin-ios-supports-unified-api-and-native-error-reporting/
Let us know if you have any questions about it.
Regards
-Jason Fauchelle
jonathanpeppers
Posted on
Feb 18 2015
Since the native stuff is working now. I have one more question.
I know Raygun Sidekick will automatically upload dSyms from archives in Xcode, but is there an option to do it command line? We already use TeamCity to make IPAs and upload them to Hockey for our beta testers, and I’d love to automatically upload dSyms to Raygun at the same time.
Jason Fauchelle
Raygun
Posted on
Feb 18 2015
Hi Jonathan,
Yes, dSYMs can be uploaded in this way. Here is a blog post that describes the dSYM upload API, and gives an example of doing this via cURL on a Jenkins build server. https://raygun.io/blog/2014/05/jenkins-dsym-upload-to-raygun/
Let me know if you have any questions about this.
-Jason Fauchelle
jonathanpeppers
Posted on
Feb 19 2015
I'm trying this method, it looks like he is emulating the Raygun website with curl.
He doesn't explain what the <token>
is in his curl example. So I've not been able to get it to work.
I tried generating a basic auth header with my credentials, tried the app's api token, and also tried using the raygun.sso cookie value I see in my browser. Can I get details on this?
I'm pretty sure I have the dSym file and app ID correct already.
Jason Fauchelle
Raygun
Posted on
Feb 19 2015
Hi Jonathan,
The <token> should be replaced with a basic auth header - username:password then base64 encoded with the RFC2045-MIME variant. Make sure to replace <token> including the angle brackets.
Let me know if that helps at all.
-Jason Fauchelle
jonathanpeppers
Posted on
Feb 19 2015
Thanks, I got it to work.
It seems like I mistyped my password when generating the auth header in Postman.
Jason Fauchelle
Raygun
Posted on
Feb 19 2015
Great to hear you got this working!
-Jason Fauchelle