Bug 41231 - Archive operation corrupts the DSYM file
Summary: Archive operation corrupts the DSYM file
Alias: None
Product: iOS
Classification: Xamarin
Component: MSBuild ()
Version: XI 9.8 (tvOS / C7)
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: 10.2.2 (C8SR2)
Assignee: Jeffrey Stedfast
: 47803 ()
Depends on:
Reported: 2016-05-21 08:18 UTC by Mohib Sheth
Modified: 2017-01-31 19:10 UTC (History)
12 users (show)

Tags: BZCU
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:

Description Mohib Sheth 2016-05-21 08:18:12 UTC
We have been facing issues with DSYM file and we asked on Xamarin Forums but without a solution


Solution we have found:

We have realized that the "Archive" option in XS messes up the DSYM for some reason. If you are using "Archive" to create your final ipa to upload to TestFlight, do this:

1) Select the Build Type (i.e AppStore/Ad-Hoc/etc)
2) Do a build (this will create IPA + DSYM files in the bin/BuildType directory
3) Make a copy of the DSYM file. This file is correct and you can upload to Insights.
4) Use the "Archive" option to create the final IPA file to upload to TestFlight. Don't use the DSYM file created after using the "Archive" option because its incorrect (you can notice the difference in the size clearly)


Xamarin Studio: Version 6.0 (build 5156)
Apple Developer Tools: Xcode 7.3.1 (10188.1) Build 7D1014
Xamarin.iOS: Version:
Comment 1 Al Clark [MSFT] 2016-05-24 13:29:01 UTC
Is this only happening on the preview channels or do you see the same thing on Stable?

Could you please provide the following:

1. Your full version info:

Xamarin Studio in OS X
Xamarin Studio -> About Xamarin Studio -> Show Details -> Copy Information [button]

2. Logs:

Xamarin for Mac logs:
You can select the "Go -> Go to Folder" menu item in Finder, and then copy and paste the path into the dialog.


This folder can also be opened via "Help -> Open Log Directory".

3. A sample that exhibits the problem.
Comment 2 Sebastien Pouliot 2016-07-06 19:29:40 UTC
Moving off the SR1 milestone as we have not received the requested information.
Comment 3 Alex Soto [MSFT] 2016-08-22 18:29:34 UTC
We have not received the requested information. If you are still 
experiencing this issue please provide all the requested information 
and re-open the bug report. Thanks!
Comment 4 Ron 2016-11-22 01:35:11 UTC
I'm currently having this issue with Xamarin 6.1.1 (build 15). Doing a Release|iPhone build creates the correct dSYM file (about 100 MB). Then when I do an Archive for Publishing build, it creates a much smaller dSYM without the symbols for my app (17 KB). I realize that the bug was closed but I'm wondering if this ever came up anywhere else and if a resolution was found. Web searches aren't turning up anything.
Comment 5 Jeffrey Stedfast 2016-11-23 16:33:25 UTC
I think I know what might be happening.

When you do your original build, as you mentioned the dSYMs are correct (@ around ~100MB). When you Archive, the Archive MSBuild target depends on the Build target and so a new build runs. In an ideal scenario, each build step would be a no-op. Unfortunately, somehow the _GenerateDebugSymbols target is running again, but because the mtouch task did not generate a new native executable, it remains stripped from the previous build and so dsymutil gets run on a stripped binary which produces a worthless dSYMs.

I suspect the solution is to fix the SymbolStrip task to restore the LastWriteTime timestamp of the native executable -or- to update the timestamp on the dSYMs Info.plist.
Comment 6 Ron 2016-11-23 16:41:53 UTC
Is there anything that I can provide you with that will help you resolve this?

This only started recently. Maybe a couple of minor releases ago. If this is happening for all users of the latest stable releases, then I don't get why there haven't been more complaints about it. It leads me to believe the issue is configuration or something else different in some environments.
Comment 7 Jeffrey Stedfast 2016-11-23 16:48:31 UTC
Hmmm, not so sure anymore because the _CodesignAppBundle target already updates the mtime timestamp of the dSYM's Info.plist file which should have had the same effect.
Comment 8 Jeffrey Stedfast 2016-11-23 20:31:12 UTC
Okay, I haven't had any luck reproducing this locally so I may need you to set your Xamarin Studio -> Preferences -> Projects -> Build -> Log verbosity to "Diagnostic" and then do the following:

1. Build -> Clean All
2. Build -> Build All
3. Copy the Build Output (Errors pad -> Build Output) to a text file
4. Build -> Archive for Publishing
5. Copy the Build Output (Errors pad -> Build Output) to a text file

Then attach the build output files from steps 3 and 5 to this bug report (individually or in a zip file is fine, whichever is more convenient)

(Note: feel free to check the checkbox that says "Make attachment and comment private")
Comment 9 Jeffrey Stedfast 2016-11-23 20:33:14 UTC
FWIW, as a workaround, try doing:

Build -> Clean All
Build -> Archive for Publishing

Let me know if that fixes things for you (obviously not ideal, but useful as a temporary workaround)
Comment 10 Brendan Zagaeski (Xamarin Team, assistant) 2016-11-23 21:33:36 UTC
> "Make attachment and comment private"

As a heads up for Jeff, note that in Bugzilla 5.0, that checkbox is not by default available to users.

For Ron, if you would like to post back the information privately, please file a new bug and be sure to pick the "Xamarin Team (Private Bug)" checkbox on [1] or the "Only Xamarins should see this bug" checkbox on [2].  (Posting a new bug has other bookkeeping advantages too, but no need to worry about those if you are content to leave the requested information public on this existing bug report.)  Thanks!

[1] https://bugzilla.xamarin.com/enter_bug.cgi?classification=__all

[2] https://bugzilla.xamarin.com/newbug
Comment 12 Brendan Zagaeski (Xamarin Team, assistant) 2016-11-23 22:01:06 UTC
Slight correction, "that checkbox is not by default available to users" should more accurately say "That checkbox appears on the 'Add an attachment' page for users, but it won't work for them: if it's enabled it will cause an error when attempting to submit the attachment."
Comment 13 Ron 2016-11-23 23:23:55 UTC
Thanks guys. I've logged #47803 with the requested info.
Comment 14 Jeffrey Stedfast 2016-11-27 19:17:22 UTC
*** Bug 47803 has been marked as a duplicate of this bug. ***
Comment 15 Jeffrey Stedfast 2016-11-29 19:27:31 UTC
Fixed in https://github.com/xamarin/xamarin-macios/pull/1261
Comment 16 Jeffrey Stedfast 2016-11-30 15:49:26 UTC
For an explanation of what is going wrong, see https://bugzilla.xamarin.com/show_bug.cgi?id=47803#c9
Comment 17 Mohit Kheterpal 2016-12-05 14:47:13 UTC
Thanks @jeffstedfast I am able to reproduce this issue with your steps mentioned in trello card using stable builds.

However with master build of X.iOS, I am observing that this issue has been fixed. using build xamarin.ios-

Hence, closing this issue by makring it as Verified.

Comment 18 Mohib Sheth 2017-01-31 05:59:39 UTC

Please read the comment in the link above. People are still facing the issue. I would suggest not closing or marking the issue as verified until the fix is released to a public build.
Comment 19 Jeffrey Stedfast 2017-01-31 19:10:49 UTC
The fix has already been back-ported to cycle8 (what is currently in stable) and cycle9.

Our policy is that we close bugs when the patches have been accepted into the appropriate branch(es).