Bug 43417 - mono-symbolicate for ios is not working properly.
Summary: mono-symbolicate for ios is not working properly.
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: master
Hardware: PC Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2016-08-16 15:23 UTC by Rajneesh Kumar
Modified: 2017-07-26 18:51 UTC (History)
9 users (show)

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

Test case, mysm folder and crash log (562.57 KB, application/zip)
2016-09-01 20:38 UTC, Peter Collins

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:

Comment 1 Peter Collins 2016-09-01 20:38:22 UTC
Created attachment 17304 [details]
Test case, mysm folder and crash log

I'm still able to reproduce this with xamarin-macios/master/d747998. I've attached the project I used as well as the mSYM folder and crash log I am trying to symbolicate.

When trying to run `mono-symbolicate` I see the following:
> Warning: MVID directory does not exist: bin/iPhone/Release/SomthingIficate.app.msym/175e2a76fa674442bfe45dac9c40e67f
I do have a `175E2A76-FA67-4442-BFE4-5DAC9C40E67F` folder in my mSYM dir, however it contains dashes and capitalization. The ID that the tool is looking for does not.
Comment 2 marcos.henrich 2016-09-02 16:19:32 UTC
Should be fixed by https://github.com/xamarin/xamarin-macios/pull/749
Comment 3 Sebastien Pouliot 2016-09-02 20:30:21 UTC
> spouliot merged commit 46e6f06 into xamarin:master 3 minutes ago

@Peter hopefully fixed this time...
Comment 4 Peter Collins 2016-09-06 15:18:04 UTC
Using master/46e6f0691 and mono-4.60-branch/3ed2bba I see a similar result as reported in https://bugzilla.xamarin.com/show_bug.cgi?id=43199#c1, even with verbose output selected. While there are no longer any errors/warnings reported by the tool in the symbolication output[0], the stack trace information for this crash is still obfuscated.

[0] https://gist.github.com/pjcollins/3772521919a0f0a3ec018802bd7fb51c
Comment 5 Luis Aguilera 2016-09-12 20:12:07 UTC
since C8 is now closed, and is shipping this week, I will move this but to the C8SR1 milestone. We'll continue working on the issue seeking it's resolution as soon as possible.
Comment 6 Rodrigo Kumpera 2016-12-21 13:10:06 UTC
Hi Peter,

I can't reproduce the conditions using the sample project you provided as it won't generate the mSYM directory.

I did the following:

- Created a new template project, added the button, added a touch up inside action.
The default action throws, which is perfect for this.

-Added -msym to the extra mtouch flags.

Build under release|simulator.

Run and get the crash.

Run through the symbolification tool with [1] applied. Get the expected results.

One thing to keep in mind, which looks like the above testing is doing. Is that the data gets invalidated if you (re)build the project (even with zero changes).

The same applies for sim x device builds.

[1] https://github.com/mono/mono/pull/4181
Comment 9 Rodrigo Kumpera 2017-01-27 13:32:15 UTC
Returning to iOS as it looks like a packaging/TestPlan issue.
Comment 10 John Miller [MSFT] 2017-07-26 18:51:03 UTC
Thanks so much for taking the time to submit this report! I attempted to reproduce this issue based on the bug description with the latest Xamarin.iOS, and I was unable to hit the problem. If this issue is still occurring for you, please reopen this report and attach a project that reproduces the issue, ideally starting with a new template project and then adding just the code necessary to demonstrate the issue.