I have two related questions actually:
If I want to be able to symbolicate crash logs from a distribution build (that is, a build I gave to someone to beta test my application - not one that is already in the appstore), should I disable the "Strip Linked Product" and "Strip Debug Symbols During Copy" options for debug or for release? In fact, would it cause any kind of problem is I disable both of them forever (even in my appstore submission)?
If I distributed a build to a beta tester, but it had enabled the "Strip Linked Product" and "Strip Debug Symbols During Copy" options, is there still a way to symbolicate their crash logs?
When you create an Archive (Build > Archive), the archive bundle will have a folder called dSYMS that contain dSYM file(s) (debug symbols file) for your application and other linked libraries. This means you can strip debug symbols from your products but keep the dSYM files to symbolicate crash reports. This post has more information on how to use the atos tool to symbolicate a crash report provided that you have the app binary and dSYM files.
In general, Debug builds have Strip Debug Symbols During Copy set to NO, and Release builds have it set to YES to reduce the binary size.
If you have distributed your application through build -> archive, you will have dSYM file associated with it. Now when you get crash report, there is no need to do anything. Drag the crash report into Xcode and it will be automatically get added to you Organizer section. If valid archive and dSYM file is available, Xcode will automatically symbolicate the crash log for you.
Related
I've recently stumbled upon a rather odd problem with Xcode which occurs when I build an IPA and attempt to install it, I've tried installing using Xcode, iTunes and iPhone Config Utility, all of which give the same error
A signed resource has been added, modified, or deleted.
I can successfully debug the app on my phone using XCode, it's only when I try to install an IPA I see the error.
I've tried unzipping the IPA and running the codesign validation tool which throws up the following response:
a sealed resource is missing or invalid In architecture: armv7
resource missing:
/Users/dev1/Documents/PoleTester.app/Settings.bundle/._Root.plist
This led me to look at the Settings.bundle file and ensure that it's being included in the build, which it is. Interestingly though, if I remove the Settings.bundle file, build an IPA and attempt to install it on my iPhone the install succeeds, however this of no use as I need the Settings.bundle file installing with the app.
Further investigations on some of my previous XCode projects has shown that I can build an IPA, with the Settings.bundle file included, and successfully install it. However, if I make a simple change to the Settings.bundle file, such as adding or removing a row, build an IPA and then attempt to install it I get the
"A signed resource has been added, modified, or deleted" error.
I'm at a bit of a loss as to what's causing this error and why the Settings.bundle file is causing the install to fail.
Has anyone seen this error before or potentially shed some light on what's causing it?
I'm using Xcode 4.6.3 and an iPhone 4 running iOS 6.1.3.
Clean Build Folder (⌘⌥⇧-K) has resolved this for me 3 out of 3 times.
I just ran into this issue using Xcode 6 beta 6 installing to my iPhone 5 running iOS 8 beta 5. The app I'm building uses a Today extension (aka widget).
It appears the issue stemmed from my having not set up dependencies properly. I have a third party framework (Alamofire) set up as part of the project as a dependency of the overall project, but not as a dependency of the today widget. I could build fine but when installing to device I would get this "signed resource has been..." error.
By adding Alamofire as a dependency of the Today widget this resolved the issue.
It's a bit late but I ran into the exact same issue today with Xcode 5.0.1.
According to https://developer.apple.com/library/ios/technotes/tn2318/index.html, "the resource missing: my.app/..*" error could be caused by:
The file prefixed with "._" is considered an AppleDouble file and it can result from copying the uncompressed Xcode project folder onto a non-HFS+ formatted disk. The AppleDouble files must be removed using the 'dot_clean' command. The Xcode project folder is the argument to dot_clean as illustrated below.
Steps I did to resolve this:
Close Xcode
Run "dot_clean /path/to/My_Xcode_Project" in Terminal
Open Xcode again and make a new build
Oddly enough most of these _* files don't seem to cause any issues except those inside Settings.bundle (Nearly every file in my directory had one, but only after I added Settings.bundle, the IPA failed to install).
I also faced the same issue and this post solved my problem:
http://code-ninja.org/blog/2012/04/17/signed-resource-has-been-added-modified-or-deleted/
It turns out that the problem was caused by having special character in the product name – in my case, a ?. Removing the ? from the product name fixed the problem.
In my case, what helped was adding a bash script into build phases (just before "compile sources"):
find ~/Library/Developer/Xcode/DerivedData -name "YouAppName.appex" | xargs -I % find % -type f -maxdepth 1 | xargs rm
What this script does, is to clean files in project's appex dir (e.g. assets), but leaving sub-directories (e.g. compiled storyboard). In effect, using this script while building is much faster to execute than full project clean.
I decided to make a separate target for my development app using Xcode 4.1. I duplicated the target, changed the bundle ID, made a new scheme. The original target was called "xxx" and the new one is "xxxDev".
The app builds, runs and debugs (sort of) correctly on the iPhone/iPad. Both versions; Dev and non-dev are on the iPhone. Only two problems:
1) when debugging, every so often xCode is not able to attach to the process it just launched.
2) I always get the warning
warning: Unable to read symbols for /Users/jon/Library/Developer/Xcode/DerivedData/xxx-eesunloavphkaraezppecayjklqw/Build/Products/Debug-iphoneos/xxx.app/xxxDev (file not found).
The file is correctly built under
/Users/jon/Library/Developer/Xcode/DerivedData/xxx-eesunloavphkaraezppecayjklqw/Build/Products/Debug-iphoneos/xxxDev.app/xxxDev
For some reason when running the debugger it is somehow holding on to the old build directory "xxx.app" and I can't find how I can change this. The scheme I am using points to the xxxDev.app executable.
I've grepped every possible file in the various directories and found nothing.
Does anyone have any ideas?
Got the same thing with XCode 4.2b5 last week-end. Reinstalling XCode did the trick for me.
I have just updated my Xcode to X.Y.Z. Now I have a problem with the symbolication of the crash logs received from my tester and even from my phone too.
When I build the AdHoc distribution I am using the "Arhive" scheme, then I create the *.ipa file singing it with my developer credentials.
Is this the issue?
And I can't find the dSym files for these AdHoc builds.
Further to coob's answer, I find adding these directories to Spotlight's ignore list (System Preferences → Spotlight → Privacy) helps:
~/Library/Developer/Xcode/DerivedData/ (Xcode 4 build artefacts)
~/Library/Application Support/iPhone Simulator/ (file system for the iPhone Simulator)
Like this:
(See this blog post for additional detail.)
Update: from a comment by joerick: "This works, but it also meant that Instruments.app couldn't find the debug symbols, so I had to remove DerivedData from the Privacy list to do some profiling." - bear this in mind if you use Instruments.
For me, neither the line 323 edit nor the Spotlight exclusions fixed it. So I tracked down the issues in symbolicatecrash and published a patched version on github. Just replace /usr/local/bin/symbolicatecrash and your iOS crash reports will start symbolicating again.
This patch may not work for Mac apps, as it makes assumptions about the structure of the .xcarchive directory which don't appear to hold for desktop apps.
Edit: you may still have problems if Spotlight hasn't indexed your archives. You can get force an index by running the following in a terminal:
mdimport ~/Library/Developer/Xcode/Archives/
More info on troubleshooting here.
The symbolication script is having an issue finding the right binary/dSYM. It uses Spotlight to do this and often cocks up. Here's a few things to try:
Make sure your .app doesn't have a
space in it.
It may be finding the version of
your app installed on the simulator
(backwards, but it sometimes does
this for me). Reset your simulator.
Clear your build directory.
I had the same issue today. From my research on the web, there is an issue with the armv6 libraries that cause the symbolicate process to fail. I found the answer in the dev forums here.
For those without access, you need to create a copy of the symbolicatecrash script from /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/. Edit the file and replace the 'die' on line 323 with a 'print' (this is why it's not working, the script fails here).
Then run symbolicatecrash against your crash log. You'll see the error from line 323, but then it will symbolicate all your lines and variables. It still fails for the system libraries, but it give enough information to fix your own bugs.
Hope this helps.
I think I had this issue, or something similar.
Xcode 4.0 wasn't showing the symbols for a crash I had from a tester.
I seemed to fix this by opening the xarchive that I had created, and copying out the dsym file from within it (right click and 'view package contents') to sit alongside it in the archive folder. I can't guarantee this was the solution - I was trying a number of other solutions at the time, but I know that I have the symbols now and didn't before. Worth trying?
To locate a dSYM file based on it's ID in a crashlog that looks like this :
Binary Images:
0x100000000 - 0x100021ff7 +com.developer.foobar 1.1 (2) <D1B7F956-7D79-3D4D-BA53-E9EBB368A9F8> /Applications/FooBar.app/Contents/MacOS/FooBar
you can do:
mdfind com_apple_xcode_dsym_uuids == D1B7F956-7D79-3D4D-BA53-E9EBB368A9F8
For OSX apps built with "DWARF with dSYM" you do not actually need the dSYM file and can use the manual approach at https://developer.apple.com/library/content/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATE_WITH_ATOS
Additionally to check the UID of a binary you can do something like
dwarfdump --uuid /Users/valexa/Desktop/GPSnote.app/GPSnote
UUID: 6194D2B0-4E61-3834-AD15-C279EB1848XX (armv7)
UUID: D1B7F956-7D79-3D4D-BA53-E9EBB368A9F8 (armv7s)
I have just updated my Xcode to X.Y.Z. Now I have a problem with the symbolication of the crash logs received from my tester and even from my phone too.
When I build the AdHoc distribution I am using the "Arhive" scheme, then I create the *.ipa file singing it with my developer credentials.
Is this the issue?
And I can't find the dSym files for these AdHoc builds.
Further to coob's answer, I find adding these directories to Spotlight's ignore list (System Preferences → Spotlight → Privacy) helps:
~/Library/Developer/Xcode/DerivedData/ (Xcode 4 build artefacts)
~/Library/Application Support/iPhone Simulator/ (file system for the iPhone Simulator)
Like this:
(See this blog post for additional detail.)
Update: from a comment by joerick: "This works, but it also meant that Instruments.app couldn't find the debug symbols, so I had to remove DerivedData from the Privacy list to do some profiling." - bear this in mind if you use Instruments.
For me, neither the line 323 edit nor the Spotlight exclusions fixed it. So I tracked down the issues in symbolicatecrash and published a patched version on github. Just replace /usr/local/bin/symbolicatecrash and your iOS crash reports will start symbolicating again.
This patch may not work for Mac apps, as it makes assumptions about the structure of the .xcarchive directory which don't appear to hold for desktop apps.
Edit: you may still have problems if Spotlight hasn't indexed your archives. You can get force an index by running the following in a terminal:
mdimport ~/Library/Developer/Xcode/Archives/
More info on troubleshooting here.
The symbolication script is having an issue finding the right binary/dSYM. It uses Spotlight to do this and often cocks up. Here's a few things to try:
Make sure your .app doesn't have a
space in it.
It may be finding the version of
your app installed on the simulator
(backwards, but it sometimes does
this for me). Reset your simulator.
Clear your build directory.
I had the same issue today. From my research on the web, there is an issue with the armv6 libraries that cause the symbolicate process to fail. I found the answer in the dev forums here.
For those without access, you need to create a copy of the symbolicatecrash script from /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/. Edit the file and replace the 'die' on line 323 with a 'print' (this is why it's not working, the script fails here).
Then run symbolicatecrash against your crash log. You'll see the error from line 323, but then it will symbolicate all your lines and variables. It still fails for the system libraries, but it give enough information to fix your own bugs.
Hope this helps.
I think I had this issue, or something similar.
Xcode 4.0 wasn't showing the symbols for a crash I had from a tester.
I seemed to fix this by opening the xarchive that I had created, and copying out the dsym file from within it (right click and 'view package contents') to sit alongside it in the archive folder. I can't guarantee this was the solution - I was trying a number of other solutions at the time, but I know that I have the symbols now and didn't before. Worth trying?
To locate a dSYM file based on it's ID in a crashlog that looks like this :
Binary Images:
0x100000000 - 0x100021ff7 +com.developer.foobar 1.1 (2) <D1B7F956-7D79-3D4D-BA53-E9EBB368A9F8> /Applications/FooBar.app/Contents/MacOS/FooBar
you can do:
mdfind com_apple_xcode_dsym_uuids == D1B7F956-7D79-3D4D-BA53-E9EBB368A9F8
For OSX apps built with "DWARF with dSYM" you do not actually need the dSYM file and can use the manual approach at https://developer.apple.com/library/content/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATE_WITH_ATOS
Additionally to check the UID of a binary you can do something like
dwarfdump --uuid /Users/valexa/Desktop/GPSnote.app/GPSnote
UUID: 6194D2B0-4E61-3834-AD15-C279EB1848XX (armv7)
UUID: D1B7F956-7D79-3D4D-BA53-E9EBB368A9F8 (armv7s)
The current issue I'm having is that Build and Archive will build my current target but after it's finished building, a pop-up will appear with the message:
"The operation couldn't be completed. No such file or directory"
I have reinstalled Xcode (3.2.3 with SDK 4.0), rebooted my machine, cleaned the cache, cleaned the project, manually deleted the project build directory. Nothing has worked.
I've also checked ~/Library/MobileDevice/Archived Applications and it is empty.
Any ideas?
p.s. This is driving me crazy!
The error The operation couldn't be completed. No such file or directory also occurs in XCode 4.0 GM preview if you do not change identity to "Don't Re-sign" after selecting (Archives) Share in the Organizer
I had this problem and the solution that was recommended to me was:
Open your Xcode project
Select Unity-iPhone in targets (Double click so it opens the info)
Find "Generate Debug Symbols" and check it on. (Just Search for it in the search field)
This worked for me, but I still don't understand why it was necessary.
All answers failed. Best solution,
drag the .app bundle to iTunes and reveal the app in Finder. Boom! you get your ipa there.
Since it only seems to happen with your release configuration, double check the "Build Locations" values in your project settings for the release configuration.
Check the paths in the "build locations" to make sure they exist
Check the permissions for those paths
Try doing just a build (no archiving) for your release configuration
Also keep an eye on your build results window during the build to see if there were any warnings during the signing and packaging stages that could give you clues
Had the same issue and none of the mentions solutions worked.
I finally found the problem when I tried to directly sign the app with the adhoc profile: it told me that I had twice a distribution profile in my keychain. I deleted the old one, then compiled again with the dev profile, and then archiving with the adhoc profile and it worked.
Longshot answer - do you have any unusual characters in your project path? This release note indicates it can cause problems:
While most known cases have been taken
care of, having a space, comma, slash,
backslash, tilde, or other character
special to the Unix shell in the
directory name of any parent folder of
your project can cause your project
build to fail in unexpected ways.
If you have a 3:rd party SDK you need to add "$(SDKROOT)/ResourceRules.plist" to the “Code Signing Resource Rules Path” key in the targets build settings.
I solved this problem by exchanging the wildcard adhoc distribution profile I was using for an app specific adhoc distribution profile.
Of the top of my head, I would check permissions. Some code reports permissions problems as there being no file/folder. Check the Console log. You will sometimes find more info there.
Did you install into /Developer? If you've customized that folder the issue could be that the path contains a space, which could be causing your problem.
Run the Console app and see what information is being spit out there. That should give us more insight into the issue.