dsymutil failed with exit code 11

Anyone else seeing this on OS X 10.8 , XCode 4.4?

I suspect it might be something triggered by having Script Debugging enabled in the build settings, but cannot reliably reproduce the build error.

 

I have the same problem, but it doesn't happen every time when I build it.

 

We have received couple of similar reports. The good news is that upcoming Xcode 4.5 does not exhibit this problem. As temporal solution you can disable dsym file generation in Xcode Build Settings as shown in attached screenshot.

 

Thanks Mantas!

 

Thanks, helped me too on 10.7.4 Xcode 4.4.1

 

I'm running Xcode 4.5 and I'm getting the problem...

dsymutil failed with exit code 11

 

I'm getting the same problem, It frustrating when we as developers want/need to update versions of software only for them to stop working which take hours of dev time to sort out or find a work around.

Are we 100% sure it doesn't happen in 4.5 and when is that released?

 

The error DOES happen in Xcode 4.5 as well.

 

you should report to bugreport.apple.com

 

Can you provide the relevant informations to share with apple to allow them to investigate it?

At the time all we know is that it happens with Unity due to the closed source engine part when script debugging is enabled (and only then) + xcode in debug with dsym which is not that much.

 

Just submit your Xcode project with detailed information what version of Xcode / dsymutil are you using. dsymutil operates on binaries, not on the source code, so you have everything needed to reproduce issue on their side.

 

Just found this thread after having the same problem. Just thought I would let anyone else know that running a clean on the xCode project seems to have solved this for me.

 

Thank you, good to know.

 

Unfortunately, a clean isn't good enough for me this time. I tried restarting the Mac, and deleting the folder inside DerivedData - still the error!

What did work was changing the Debug Information Format to plain DWARF in Build Settings.

 

I get this almost on every project if I set the Development Build+Autoconnect Profiler+Script Debugging

 

Yeah. The same for me (xCode 4.6). And switching to plain DWARF helps, but I can see no stacktrace in log anymore...

 

I to am suffering from this. Have been for a long time. But now I NEED to actually debug something one device. Works fine in the editor. Unity needs to get their act together and FIX THIS> It has been hanging around for FAR TOO LONG!

Very disappointed.

= Ed =

 

Please submit a bug report to Apple (http://bugreport.apple.com).
It's a best way to get this fixed with next Xcode tools release.

 

I've seen this suggestion posted a number of times. But Xcode seems to work fine - along with DSYMUtil - for pretty much any other project not built with Unity Pro. This would seem to me to point a very suspicious finger at Unity. Rather than washing your hands of this problem, it would seem that THIS is exactly the sort of thing that we are paying you for with our Pro Licenses. Can YOU build a realistic project and debug on device with Script Debugging turned on? I would suggest that you cannot. yet you advertise this as a feature of Unity Pro. This is what we paid for.

Instead you wash your hands of the problem and tell us to bug Apple about it - when it only seems to occur with Unity builds? Sorry to push back on you Mantas, but your response is completely unacceptable from where I sit. Give me one good reason why all of us should have to chase down this problem individually, rather than Unity resolving the problem with its build system.

I remain deeply disappointed.

= Ed =

 

If this was in Unity Answers, I would upvote this, and then, create 20 more accounts, spend days in gaining reputation, then come back and upvote with each and every one of them.

Unity management cares very little about mobile devices, as it would seem.

 

And the silence from Unity is deafening...

= Ed =

 

This only happens with unity builds which are built in development mode and profiler/debugger enabled. You won't get this when building for an app store release (meaning no development build and not using profiler/debugger); then you can have proper debug symbols using DWARF and a DSYMs file.

 

Yes, of course, this has already been noted by a number of people. Of course, you cannot tether the iOS device to your computer to actually debug on device, as advertised by Unity. This is a feature that has been advertised for some time by Unity to be functional. There are even instructions on how to do this. Of course that is all moot now since you cannot do this.

Unity is still culpable and notably silent on all of this, IMHO. Their only response so far has been to tell all of us to send bug reports to Apple about this consistent problem with Unity development builds.

I'm sorry azeitler. This is no excuse for Unity on this issue. Those of us who have been dealing with this problem for many months now have long known that we can properly build release builds. That does not help when you need to debug something on device.

= Ed =

 

+1 GonzoCubFan

BTW, having spent a few thousand dollars on Unity I really expect more support on blocking issues like this one

 

I am not sure about it but shouldn't you be able to connect the debugger when doing a debug-build but setting xcode to DWARF-only? I mean, remotely connecting the debugger should have nothing to do with the DWARF-setting, shouldn't it?

 

To a non-Xcode person like myself that's some strange language... what I expect is a solution by Unity. If a solution is to manually set something in Xcode then I expect that to be clearly stated in the docs. If it's a proper workaround I expect Unity to state so and give me some guidance/screenshots and to fix it ASAP.

 

And this is one of the reasons I am not in a hurry to get a pro license... I expect better support for a $400 software and royal support for $4500.

 

Actually it's $5.500 per seat

 

I will need crowdfunding for this then...

 

Why didn't I have that thought??

 

Mantis gave you everything you need to know to at least try if this might fix your problem, which it might. Can you try it and let me know if it works?

 

I posted 7 months *after* Mantis' post, so... question: are you assuming I didn't read back? If I post about this error 7 months after a "temporary fix" (and I'm not alone!) do you really assume that we are all buggers? That post dates back in August 2012, and the bug is still there! A few Unity versions have been released since then, so... what's keeping Unity from finally deliver us a fix? I'm not a bugger... I'm a paying customer dealing with a blocking issue that is well known to Unity Tech. so please... let Unity people answer for Unity Tech... at least they don't assume we're stupid.

 

Moreover: how on earth do you debug without the DSYM?

 

Okay, first of all, let's sort out the terminology:
Debugging – happens in Xcode by inspecting code for bugs, relying on a debugger which gives you stack traces and stuff. in order to do this properly you need Debug Symbols or short DSYMs so xcode can map the stack trace adresses to the method calls in your code.

Script Debugging – happens in MonoDevelop by connecting MonoDevelop to your app running on the device. This is called script debugging and does not require Debug Symbols (i just confirmed this doing a test build). It only allows you to inspect your Unity scripts – and it most likely will not work while XCode is debugging your app (i.e. when your "running" your app from Xcode).

The factors which influence how Xcode behaves and whether you successfully can build and Debug or build and Script Debug the app are these:
1. Build Settings in Unity: Script Debugging enabled, Development Build enabled:
Result A: Xcode builds with Debug Information Format set to DWARF (meaning no DSYMs file is created during build) – script debugging works (once the app is stopped in xcode and launched again manually). This is what I call 'building without debug symbols'
Result B: Xcode builds with Debug Information Format set to DWARF with dSYM file, build in xcode may take along time OR fail (with a message about the dsymutil as mentioned in the title of this thread). Script debugging works (once the app is stopped in xcode and launched again manually). This is what I call 'building with debug symbols'
my experience: use this scenario together with result A to script-debug your app

Okay, so script-debugging works for me. What about objective-c level debugging in xcode?
As just explained we need a DSYM file for that, so we need to set Xcode's build setting "Debug Information Format" to DWARF with dSYM file.
However, we might run into result 1B, which would make it impossible to build and run the app for debug purposes (or even build it at all).
To fix this we could switch "Debug Information Format" to DWARF. Which would make the app build successfully but will cause stack traces without Method-name references thus making objective-c level debugging impossible.

My solution
I first do my Script-level debugging using Scenario 1A or 1B, then I re-build my unity app (in unity) with this scenario 2:
2. Build Settings in Unity: Script Debugging disabled, Development Build disabled.
Now, I cannot do any Script-Debugging AT ALL, which means I cannot connect MonoDevelop to the app running in the device (it won't show up in MonoDevelop because the unity build did not have "Script Debugging " enabled so the app won't broadcast a signal for MonoDevelop to receive).
BUT in my experience building with Xcode's build setting "Debug Information Format" set to DWARF with dSYM file works. At least with a 50% success rate.

So, to summarize: it's a pain. But it's not impossible. And: the pain is not caused by unity or the unity editor but rather by Xcode and the code compilation tools it uses. This is a bug in dsymutil which is used to create the DSYMs file. Apple needs to fix it but given that only Unity developers appear to be experiencing this issue (I looked for bug reports on the matter and did not find any) its not a priority or not even on their radar.

 

Isn't this exactly the same problem we have before? We are attempting to debug a build on device with stack traces, but about 50% of the time we get errors that prevent the build from going through?

Either way, it seems like a problem with xCode, so I guess we need to submit bug reports to them.

 

How is this an Xcode problem if it does not happen with Unity 3.5 (or to anybody other than Unity developers....)?

 

I saw it with 3.5, but less frequently.

Edit: Probably related to how much script debugging I did on the last project. Also; there have been xCode updates between now and 3.5... perhaps one of those caused them? (This could make it seem like the Unity upgrade caused it, if xCode was updated around the same time).

 

Well, since I had way too many issues with 4.x, especially unexplained, non-traceable crashes, I went back to 3.5 and am almost 100% positive I haven't seen this error at all.

In any case, if any one of us is more right than the other (i.e. does not happen, or happens less frequently) it still hints that this is a Unity issue and not Xcode - or at least, it hints that something can be done on the Unity side to minimize or eliminate the problem.

At least this is how I read the map.

 

Andreas,

what part of my previous messsage you didn't get? You sound patronizing and like "hey guys... I know better...", but you are just a student trying to make a nice effect on Unity... maybe you have applied fo a job with them?

Honestly man, stop it. I'm 53, I've lead teams of developers for 20 years, and I've been working as developer myself for 32, so... do you really think I need to learn the basics from you? I'm well aware that in pain and twisting here and there almost everything can be done... but as a paying customer I do not appreciate this at all. I do not enjoy wasting my time to work around bugs in a product that I have paid $5,500 per seat in version 3 and then fully upgraded to version 4, that's more than $8k so please... my customers would kill me for less

 

maybe we can pool our resources and submit a bug report to apple or, again, with more pull, to unity?
I never experienced this issue in any of the demo projects I put together to submit alongside a bug report. It only occurs in my big, day-to-day projects and those are way to big to send along with a bug report. Anyone has a small, contained project with which this is an issue?

Btw. I can confirm it happens with Unity 3.5 as well as Unity 4. I am still on 3.5 for various reasons and this is still a big issue.

 

They do have at least my bug report, but I guess many of us have submitted it.

 

I just got this error when trying to build with newest version of xcode

 

Hey guys, I was able to get around this issue by cleaning the XCode build folder and not just cleaning the build. The difference is that cleaning the build folder will delete all the existing products (like the dsym) and regenerate rather than trying to append to an existing corrupt file.

To do that, go to the Project menu, hold down the option (alt) key, and "Clean" should change to "Clean Build Folder". See if it works for you now.

 

Are you getting it frequently enough to reproduce with Xcode 4.5.2/4.5.3? If that's the case please submit your Xcode project as bug report and ping me via PM with case number. At WWDC we spoke to Apple engineers about such problem, but they were not aware about any repro cases with latest stable Xcode.

 

Just to confirm something. This works for me and let's the build run successfully. I also get correct script debugging. Seems like the dSYM file isn't even needed somehow...

 

I am seeing this error with Unity 4.2.0f4 and Xcode 4.6.3 (4H1503). I have the Xcode project (rather large unfortunately) ready for a bug report submit. Mantas, are you still available to take a look if I PM you?

 

Yes, I'm very interested in that. Please let me know you case number.
Thanks!

 

I'm also getting this same exact error with the same exact versions of xcode and unity.

 

Please submit your Xcode project too.
Thanks!

 

Just in case anyone's hopeful that this will go away in Xcode 5... I've just suffered this failure for the first time on the latest developer preview :-(

Switching to just DWARF format solved the problem, but that's really not the point for such expensive software...