Bug 27419 - dSYM not archived correctly after migrating to Unified API
Summary: dSYM not archived correctly after migrating to Unified API
Status: RESOLVED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: Tools ()
Version: XI 8.6.0
Hardware: PC Mac OS
: --- normal
Target Milestone: 8.10
Assignee: Jeffrey Stedfast
URL:
Depends on:
Blocks:
 
Reported: 2015-02-25 12:11 UTC by Lucas Romero
Modified: 2015-03-06 14:12 UTC (History)
3 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 Lucas Romero 2015-02-25 12:11:13 UTC
I have a problem that started appearing after we migrated our Xamarin.iOS project to the new Unified API.
Since then, I have no working dSYM files for our releases in the archived builds.

When the first crash report came in, I tried to symbolicate it and when it did not work, I noticed that the *.dSYM file was only 29 KB small, when it was previously 23 MB in size (single architecture, armv7).

I tried rebuilding the project (using AppStore configuration), and a dSYM file appeared in the bin folder with around 40 MB in size (fat, armv7+arm64). It was a valid dwarf file and contained info for both slices (armv7, arm64). But as soon as I hit "Archive" from the "Build" menu, the dSYM file shrank down to 29 KB (both in the bin dir as well as in the resulting *.xcarchive) and was no longer of any use.

I was able to get my crash reports symbolicated by checking out our release tag from git, building it and using the resulting dSYM against the crash report where I patched the dwarf uuid manually to match the dSYM just produced, but it is annoying having to archive the dSYM separately.
Comment 1 Sebastien Pouliot 2015-02-25 14:18:24 UTC
@Lucas can you give us all* versions information ? this step is shared a bit between the msbuild task and XS.

* The easiest way to get exact version information is to use the "Xamarin Studio" menu, "About Xamarin Studio" item, "Show Details" button and copy/paste the version informations (you can use the "Copy Information" button).
Comment 2 Jeffrey Stedfast 2015-02-25 15:29:38 UTC
When we archive, we just do a recursive copy of the dSYMs dir using File.Copy() so I dunno why the files are getting truncated in your case.

Created a simple test case (new Unified SingleView app project) and was not able to reproduce this problem.
Comment 3 Jeffrey Stedfast 2015-02-25 15:30:35 UTC
Tested in Xamarin Studio 5.7.2 (build 2) w/ Xamarin.iOS 8.6.2.22
Comment 4 Lucas Romero 2015-02-25 15:42:46 UTC
Hi Sebastien, hi Jeffrey!

Wow, very fast response from you guys! I have appended the version information below.
I am not sure if I brought it across correctly, reading Jeffreys comment about File.Copy():
The dSYM sits in the bin/AppStore folder, looking healthy after after a "Rebuild all" in AppStore configuration. Then, I press "Archive". The build process starts (which does not need to compile anything, because nothing changed) and afterwards, the dSYM that was a healthy 40 MB before is truncated to 26 kb (didn't take a look at the contents yet). And thats the file that ends up in the xcarchive.

=== Xamarin Studio ===

Version 5.7.1 (build 17)
Installation UUID: d7e1ac86-9ec7-4c05-8f0a-8efafedfb286
Runtime:
	Mono 3.12.0 ((detached/de2f33f)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 312000076

=== Apple Developer Tools ===

Xcode 6.1 (6604)
Build 6A1052d

=== Xamarin.iOS ===

Version: 8.6.1.26 (Indie Edition)
Hash: 98ee412
Branch: 
Build date: 2015-02-11 04:37:05-0500

=== Xamarin.Mac ===

Not Installed

=== Build Information ===

Release ID: 507010017
Git revision: 0bc7d3550b6b088ac25b08dcf7bbe73bcc8658b3
Build date: 2015-02-03 19:43:29-05
Xamarin addins: f7b7d34419c9ec24501bfa7c658e80a6305613e0

=== Operating System ===

Mac OS X 10.9.4
Darwin ferdinand.lan 13.3.0 Darwin Kernel Version 13.3.0
    Tue Jun  3 21:27:35 PDT 2014
    root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64
Comment 5 Jeffrey Stedfast 2015-02-25 16:05:09 UTC
Okay, so when you Build, it generates the correct dSYM output.

But then when you Archive (which causes a rebuild), somehow the dSYM dir is corrupted.

If that's the case (did not happen to me when I tested again after reading your comment, because I originally just did Archive w/o building first because Archive forces a Build), then this is a bug in mtouch (which is what generates the dSYM dir).
Comment 6 Lucas Romero 2015-02-25 16:10:22 UTC
That's correct. I will try to see if I can reproduce the bug using the sample you mentioned.
Comment 7 Jeffrey Stedfast 2015-02-25 17:05:59 UTC
thinking about this some more, I think what is happening is this:

When you Build, it ends up calling mtouch which does a few things (in order):

1. compiles the app to native
2. calls dsymutil to generate the dSYM directory
3. strips the native executable

When you Archive, it internally calls Build again to make sure that the project is built.

In this second Build, mtouch is again called which I suspect decides that the binary is newer than the .exe and so skips compiling to native (optimization).

Then mtouch calls dsymutil which is now invoked on the stripped native binary and so produces a reduced dSYM directory.

And then it calls strip on the stripped binary which effectively does nothing.
Comment 8 Lucas Romero 2015-02-25 17:32:37 UTC
I think you are right. Just hit the bug again and tried again with Clean All + Archive instead of Rebuild All + Archive and it worked. Good to know!
I will always use Clean All in the future since starting a build twice is a waste anyways, but I would still consider it a bug worth fixing since it seriously hinders your ability to trace crashes in production (although you can work around it as I mentioned if you are versioning your code).
Comment 9 Lucas Romero 2015-02-25 17:35:18 UTC
Oh, and thanks for the phenomenally fast help! Love the product, love the support.
Comment 10 Sebastien Pouliot 2015-02-26 16:42:14 UTC
That's definitively something we want to fix :-)

Thanks for confirming that fixed your issue!
Comment 11 Rolf Bjarne Kvinge [MSFT] 2015-03-05 07:17:23 UTC
@Jeff, this happens with current MSBuild tasks (those that run dsymutil/strip, and tell mtouch not to) as well.

Log for initial build: https://gist.github.com/rolfbjarne/8565e2bc1fb63141e3f3 and then Archive: https://gist.github.com/rolfbjarne/fbe45d5c40cba62347fb

I think we should target this for cycle 5.
Comment 12 Jeffrey Stedfast 2015-03-06 14:00:02 UTC
Ah, it looks like the problem is that the tasks  were checking for appname.app/appname.exe which didn't exist, so ran mtouch *again* and then from there ran dsymutil/strip/etc.

I've updated the targets to check the timestamp of the actual native executable now, so this should be solved in git master.