Bug 33804 - Filenames and Line numbers are missing from crash reports on managed code
Summary: Filenames and Line numbers are missing from crash reports on managed code
Status: RESOLVED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: (C7)
Assignee: Rolf Bjarne Kvinge [MSFT]
URL:
Depends on:
Blocks:
 
Reported: 2015-09-08 18:24 UTC by Bernie Habermeier
Modified: 2016-01-11 10:16 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Bernie Habermeier 2015-09-08 18:24:15 UTC
We are unable to produce filenames and line numbers from crash reports on iOS (and Android), when compiling a Release build.  

I understand that to produce this information we will need access to the .dsym file which is not available at run time, but we need a documented process for which we can accurately produce filename and line numbers (via a script and/or you can add to Insights).  Either my understanding is not complete and I need someone to document exactly how to do this, or there is a bug with the implementation that attempts to capture the managed code IPS / offsets, or the dsym file generation doesn't get the appropriate filename / line numbers.

forums thread: http://forums.xamarin.com/discussion/10704/releasing-app-with-debug-symbols/p1

Sometimes I don't get the managed code IPS addresses:
See: http://forums.xamarin.com/discussion/comment/131511/#Comment_131511
See: http://forums.xamarin.com/discussion/comment/134428/#Comment_134428

And when I do, things still don't really work out when trying to figure out filenames and line numbers:
See: http://forums.xamarin.com/discussion/comment/102143/#Comment_102143
Comment 1 Rolf Bjarne Kvinge [MSFT] 2015-09-10 07:33:35 UTC
From what I remember from the forums, you're trying to:

* Collect information about a managed exception at runtime, and post that information to a server.
* Process that information on your server, and produce a stack trace with file names and line numbers.

Is this correct?
Comment 2 Bernie Habermeier 2015-09-10 12:15:23 UTC
Yes Rolf.  That is exactly correct.
Comment 3 Rolf Bjarne Kvinge [MSFT] 2015-09-11 04:36:31 UTC
OK, right now there's nothing officially supported right now, but I'll investigate a bit internally and see if I can come up with a procedure that works.

It might take a little time since iOS 9 (and WatchOS and tvOS...) is around the corner.
Comment 4 Bernie Habermeier 2015-09-11 13:02:37 UTC
I get it -- there is loads of work to do with iOS 9 and the other xOS's that apple is producing.

Obviously this issue is very important to us, because when things crash in the field -- the bugs by their very nature are hard to reproduce.  Easy to reproduce bugs are taken care of... without filenames and line numbers it makes a tough problem even harder to track down.

By the way -- what does it mean that "there is nothing officially supported right now"?  I assume this means that Xamarin isn't officially supporting this effort right now?  I'm asking because our sales rep who I'm talking with was saying that "Apple needs to support this".  But I don't think that's the case, right?  This is a feature whose support would come from Xamarin.  

AFAIK, the process is to make sure we can get the instruction pointer / call stack from the .NET runtime at the time of the crash, and then we have to have a valid mapping that was hopefully generated correctly for the .dsym file.  Assuming we can nail the math that plays with the runtime memory offsets of the crash report, it all should theoretically work together.

I assume the thing that requires "support" is making sure the compiler produces the correct .dysm mapping, and that when we try to get after the IPS that all that is working properly... which I presume is in the purview of Xamarin.

I'm unclear on who actually works on the mono implementation... if that is Xamarin or another group (or maybe a bit of both).  Anyhow...  Just trying to parse this (without sounding too critical).
Comment 5 Rolf Bjarne Kvinge [MSFT] 2015-09-14 04:08:01 UTC
(In reply to comment #4)
> I get it -- there is loads of work to do with iOS 9 and the other xOS's that
> apple is producing.
> 
> Obviously this issue is very important to us, because when things crash in the
> field -- the bugs by their very nature are hard to reproduce.  Easy to
> reproduce bugs are taken care of... without filenames and line numbers it makes
> a tough problem even harder to track down.
> 
> By the way -- what does it mean that "there is nothing officially supported
> right now"?  I assume this means that Xamarin isn't officially supporting this
> effort right now?  I'm asking because our sales rep who I'm talking with was
> saying that "Apple needs to support this".  But I don't think that's the case,
> right?  This is a feature whose support would come from Xamarin.  

There's nothing officially supported, because there's no official API to get the native memory addresses of a stack trace from managed code.

> 
> AFAIK, the process is to make sure we can get the instruction pointer / call
> stack from the .NET runtime at the time of the crash, and then we have to have
> a valid mapping that was hopefully generated correctly for the .dsym file. 
> Assuming we can nail the math that plays with the runtime memory offsets of the
> crash report, it all should theoretically work together.
> 
> I assume the thing that requires "support" is making sure the compiler produces
> the correct .dysm mapping, and that when we try to get after the IPS that all
> that is working properly... which I presume is in the purview of Xamarin.

Our AOT compiler produces correct .dSYM mappings (which might be a line or two off due to optimizations, but that's also happens in any other optimized language, not just C#), since otherwise crash reports (the ones that show up in Xcode's Organizer when a native crash occurs) wouldn't have correct file/line number information.

> 
> I'm unclear on who actually works on the mono implementation... if that is
> Xamarin or another group (or maybe a bit of both).  Anyhow...  Just trying to
> parse this (without sounding too critical).
Comment 6 Rolf Bjarne Kvinge [MSFT] 2016-01-08 17:11:15 UTC
Fixed.

maccore/master: aee51dbec14dd958ae3a046723c1281d0a1e0e8e

In the next major release we'll:

* Create a app.msym directory with the necessary information to symbolicate managed stack frames offline.
* Ship a mono-symbolicate tool that can process the app.msym data and symbolicate accordingly.
Comment 7 Bernie Habermeier 2016-01-08 21:29:18 UTC
That is terrific news!  What is the "next major release" called, and when could I expect it?
Comment 8 Rolf Bjarne Kvinge [MSFT] 2016-01-11 10:16:55 UTC
@Bernie, next major release will probably be Xamarin.iOS 9.6 (but the actual number may change if Apple releases new iOS versions first).

The first alphas (Xamarin.iOS 9.5) will likely be out in a few weeks.