Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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.
@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).
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.
Tested in Xamarin Studio 5.7.2 (build 2) w/ Xamarin.iOS 220.127.116.11
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
Mono 3.12.0 ((detached/de2f33f)
GTK+ 2.24.23 (Raleigh theme)
Package version: 312000076
=== Apple Developer Tools ===
Xcode 6.1 (6604)
=== Xamarin.iOS ===
Version: 18.104.22.168 (Indie Edition)
Build date: 2015-02-11 04:37:05-0500
=== Xamarin.Mac ===
=== 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
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).
That's correct. I will try to see if I can reproduce the bug using the sample you mentioned.
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.
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).
Oh, and thanks for the phenomenally fast help! Love the product, love the support.
That's definitively something we want to fix :-)
Thanks for confirming that fixed your issue!
@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.
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.