Probably a silly question. When running my project on the Device in the debug mode I get a lot of warnings al having the following string:
warning: Unable to read symbols for
/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2.1
(8C148a)/Symbols/System/Library/PrivateFrameworks/
I think its due to the space between "4.2.1" and "(8C148a)". How can i get rid of it? It must be a setting somewhere in Xcode.
I dont have these warnings on the simulator.
thanks in advance, Christian
I was getting:
warning: Unable to read symbols for /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2.1 (8C148)/Symbols/usr/lib/info/dns.so (file not found).
Version 4.2.1 does not include 'info/dns.so'. At least that was the case for me. However, it does exist in the 4.2 directory and is pointed to by the /DeviceSupport/Latest shortcut. I simply copy-pasted 'info/dns.so' to where the debugger was looking for it and that seemed to fix the warning.
I had this issue with 4.2.1 (8C148a), which I believe is caused by differing DeviceSupport files on the phone and in XCode. I tried many things, but eventually resolved it by deleting this folder:
/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2.1 (8C148a)/
After this I plugged in my iOS device and was asked to connect and restore the symbol files from the device, and it worked normally again.
When you plug an iOS device (iPad) with a slightly newer OS than the the ones in the SDK, a button to download new symbols should appear in the Organizer window of Xcode. Hit it and wait.
I've seen errors like that when my device wasn't on the same version as what I was building for. Are you sure you're not on a 4.2 beta?
I don't think 8C148a is "final"; final builds numbers never seem to end in a letter (my phone is reporting "4.2.1 (8C148)"). I haven't debugged apps on it yet (I got bored waiting for it to extract symbols and went home).
4.2 GM was 8C134, so you're certainly running newer software, but something somewhere is getting the build number wrong.
But I digress.
What directories are in /Developer/Platforms/iPhoneOS.platform/DeviceSupport? If "4.2.1 (8C148a)" doesn't exist but "4.2.1" does, you might have luck doing something like this in Terminal:
cd /Developer/Platforms/iPhoneOS.platform/DeviceSupport
ln -s "4.2.1" "4.2.1 (8C134a)"
Equivalently, if "4.2.1 (8C148)" exists, do something like this instead:
ln -s "4.2.1 (8C148)" "4.2.1 (8C148a)"
You can generally use this trick to get Xcode to talk to a beta device without installing a beta SDK; this is useful if your company has some people running the beta (for testing purposes) and other people on the latest "final" (for release purposes).
There's a mismatch at the moment, where the released version of 4.2.1 is ahead of the SDK version 4.2
#Khrob's comment fixed it for me though!
Until they provide a solid SDK, a cool workaround is to :
1 - select the Executable ( In 'Executables' in the project browser ),
2 - get info and turn off "Break on Debugger() and DebugStr()"*
Cheers, and best wishes for 2011.
T
This does not disable NSLog.
I have 4.2.1 on an iPhone 3G and Xcode 3.2.5 running on a MacBook Pro with 10.6.6. After a clean install of Xcode, I was getting the prompt to download symbols for 4.2.1 after plugging in my iPhone. After the transfer, I would no longer get the prompt when attaching the iPhone, but I was getting tons of "unable to read symbols" messages.
First, what did not work for me:
Creating symbolic link to '4.2 (8C134)' with the name '4.2.1 (8C148)'
Creating symbolic link inside directory '4.2.1 (8C148)' like there is in '4.2 (8C134)' to the ../../Developer/SDKs/iPhoneOS4.2.sdk
Both of the above caused the 'UUID mismatch' errors for several libraries. GDB would start but appear to hang.
Finally, what is currently working for me:
% cd /Developer/Platforms/iPhoneOS.platform/DeviceSupport
% mkdir '4.2.1 (8C148)' # if it does not exist
% cd '4.2.1 (8C148)'
% cp ../4.2\ \(8C134\)/DeveloperDiskImage.dmg* .
% cp -r ../../Developer/SDKs/iPhoneOS4.2.sdk Symbols
Attempt to run debug session for an application and watch the Console. For each warning about a UUID mismatch, remove the file indicated in the log message (I had AudioToolbox, CoreMedia, and some others)
Stop GDB and try again, hopefully with success
At least for my application under development, everything now works fine. Hopefully, Xcode 4.0 will clear this up.
Related
I'm running the very latest version of xcode (4.2.1). And I'm signed up to the ios developer program.
When I create a new iOS Application for iPhone or iPad, using storyboards or not it doesn't seem to matter, xcode crashes on me when I try to open the .xib or .storyboard files.
Here is the error provided when I click on the storyboard file before it crashes.
ASSERTION FAILURE in /SourceCache/IDEInterfaceBuilderCocoaTouch/IDEInterfaceBuilderCocoaTouch-933/IB Plugin/Utilities/IBObjectMarshalling.m:179
Details: Interface Builder encountered an error communicating with the iOS Simulator. "Interface Builder Cocoa Touch Tool" (54332) failed to launch and exited with status (null), signal 10. Please check Console.app for crash reports for "Interface Builder Cocoa Touch Tool" for further information.
Function: NSDistantObject<IBCocoaTouchToolProtocol> *IBAttachToCocoaTouchTool(IBCocoaTouchTargetRuntime *)
Thread: <NSThread: 0x40010a260>{name = (null), num = 1}
Something to do with the iOS simulator? Exactly the same message appears when I try open an .xib file.
When I try to run or test a project I get an error when it tries to compile the storyboard or xib files. eg
CompileXIB EmptyViewTest/en.lproj/com_markstewart_comViewController.xib
cd /Users/mark/Sites/_iOS/EmptyViewTest/EmptyViewTest
setenv IBC_MINIMUM_COMPATIBILITY_VERSION 5.0
setenv PATH "/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Developer/usr /bin:/usr/bin:/bin:/usr/sbin:/sbin"
setenv XCODE_DEVELOPER_USR_PATH /Developer/usr/bin/..
/Developer/usr/bin/ibtool --errors --warnings --notices --output-format human-readable-text --compile /Users/mark/Library/Developer/Xcode/DerivedData/EmptyViewTest-dxxqhrayajehooezj flgyjqysqkp/Build/Products/Debug-iphonesimulator/EmptyViewTest.app/en.lproj/com_ markstewart_comViewController.nib /Users/mark/Sites/_iOS/EmptyViewTest/EmptyViewTest/EmptyViewTest/en.lproj/com_m arkstewart_comViewController.xib --sdk /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0 .sdk
Please help! How do I get this to work again?
I've since totally uninstalled and re-installed developer tools. Same problem still occurs. It seems to be something to do with the iphone simulator as when I try to run the simulator app by itself it instantly crashes too. (see attached screenshot). What is going on?! :(
----- UPDATE 2
Still having this problem! I can sometimes build applications, but as soon as I click on either the .xib or .storyboard file (in separate projects) xcode crashes. When they do succeed I get the error above that the simulator has issues locating the SDK.
I've uninstalled and reinstalled xcode about five times now and the same issues keeps occurring.
Here is the crash report from the "Interface Builder Cocoa Touch Tool" error. If it makes sense to anyone? Crash Report
Does anyone have any other ideas? Starting to get pretty desperate.
did you installed TotalFinder?
I had the same problem caused by TotalFinder's Asepsis feature.
Asepsis current Version (1.1) Conflicts with Xcode 4.2 and Glims (see image).
The Website lists this known issue:
Xcode 4.2, iOS 5.0 Simulator
Some developers reported that Asepsis breaks iOS 5.0 Simulator and
causes Xcode 4.2 fail in loading XIB files
to uninstall just run this command from Terminal:
sudo open /System/Library/Extensions/Asepsis.kext/Contents/Resources/Asepsis\ Uninstaller.app
I had this same problem and deleting everything in your "Derived Data" folder fixed my issues. In your case: /Users/mark/Library/Developer/Xcode/DerivedData/EmptyViewTest
Maybe this thread will help:
How can I safely delete in my ~/Library/Developer/Xcode/DerivedData directory?
It's a pretty fundamental problem and so unlikely it's anything you're doing wrong. I'd suggest reinstalling Xcode. If that doesn't work, try uninstalling it first and install it again. (Bit of a pain, sorry. Stock up on coffee first.)
I hate to say it, but it sounds like you may need to do a clean system install followed by a clean XCode install.
Or do you have another machine you can try a clean install of XCode on first?
If you can't just create a new project and run it in the simulator without it crashing you either have an issue with XCode or with your system. Since reinstalling XCode you still have an issue, I am afraid that leaves your system in question.
Try removing (you can try just moving them rather than deleting them) these user directories. Make sure your developer tools are not running when you do this.
~/Library/Application\ Support/iPhone\ Simulator
~/Library/Application\ Support/Developer
~/Library/Developer
These directories are particular to your user.
I have same problem within xcode4.5 and iOS6. When I startup iOS simulator 6, it always report "The simulated application quit" and ask me to switch SDKS. Whatever I choose the right location of SDK5.0 or SDK6.0 for the simulator, the problem is still here. So I can't run even a simplest program with SDK6.0, but the old projects with SDK5.0 are ok.
I don't why, because it works well before today. So I follow #quellish's way, close xcode and simulator, remove these directory in my finder:
~/Library/Application\ Support/iPhone\ Simulator
~/Library/Application\ Support/Developer
~/Library/Developer
Then run Xcode again, everything goes ok again! thanks quellish!
I think some files in these directory was broken, so the strange problem happened. If someone know exactly why it happened, it's appreciate you can tell 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)
This is the first time I've used the newest xcode (3.2.5) and the new iOS (4.2.1) and I'm getting the following run time error as soon as I run my application on my device:
Unable to read symbols for /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2.1 (8C148)/Symbols/Developer/usr/lib/libXcodeDebuggerSupport.dylib (file not found).
Does anyone have a cohesive answer to fix this? And yes I know there is another post on this topic, but it has not made any progress and there is not a clear cut answer.
Thanks!
What I just did to solve this problem was:
cd /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2.1 (8C148)/Symbols
and created the symlink was missing:
ln -s ../../4.2\ \(8C134\)/Symbols/Developer/ Developer
It solves my problem.
I'll post it in the other question also.
I'm not sure what you've done to try to solve it, but here's what I'd do, retrying between each step:
If you have that path but don't have the file, get it from someone (I'll volunteer). I'm guessing it's not that easy, though. :)
Delete and reinstall Xcode.
Go to the Xcode Organizer and plug in your device, and let it authorize and download the 4.2.1 stuff.
Do you even have a directory like that? I don't have those subdirectories (I don't have a 4.2.1 (8C148) directory but I do have 4.2.1 (8C148a)) there. Under DeviceSupport/Latest/ I have those subdirectories and files.
Since upgrading to Xcode 3.2.1, I've experienced a strange issue that has really killed my workflow. The issue only exhibits itself under my own user account (the same project opened by a different user works fine). Therefore, the heart of this question is, "what does Xcode load from the user directory that could conceivably cause this issue?"
(System: Snow Leopard 10.6.1; Xcode 3.2.1 w/ iPhone SDK 3.1.2)
Symptoms:
Code completion only works on symbols of the current class or already referenced in the class. Virtually useless.
Document/reference lookups (i.e. option-double-clicking on an identifier or symbol returns this strange result): "Documentation not found for the symbol 'symbol name'. Click here to view symbol declaration."
Like I said, since other users are experiencing normal behavior in Xcode, this must be due to something only loaded for my user account. I've already eliminated ~/Library/Preferences/com.apple.Xcode.plist, ~/Application Support/Developer,~/Application Support/Xcode`.
The only thing I've recently installed is mogenerator (the defunct xmod integration may have killed it, but it doesn't install anything to the user directory)
Update: 10/26/09
This one is really starting to kill me. I did a fresh OS X install, followed by an Xcode 3.2 install from the Leopard disc, followed by an iPhone SDK install from the ADC site, and this started occurring again within 30 minutes of my having started working. I'm at an utter loss. The error is most obvious when option-double-clicking on a symbol (say, the NSString class) and instead of getting the documentation snippet, a message "Cannot determine the symbol for the current selection." appears.
Update: 10/26/09 #2
I just tried creating a fresh project, and that project's symbols are appearing fine. So the issue is apparently local to my project. Hopefully that's a better start. To demonstrate what I'm talking about, here's a screen of the issue manifesting itself with respect to documentation:
Have you tried rebuilding your CodeSense index? Project > Edit Project Settings > General >
alt text http://idisk.mac.com/cdespinosa/Public/Rebuild.png
After doing that, check Console.app to see if Xcode issued any warnings. It's possible that some of your source code causes the indexer to stop, and you don't end up with a valid index. Filing a bug with Apple and providing the source, if possible, would help Apple fix problems like this.
This is the first thing I'd try:
alt text http://img.skitch.com/20091026-ek3id5s121wqrsiu8apwm4qgir.png
Wait until it doesn't say "Getting" anywhere anymore before doing anything documentation related.
Given the clues from the console:
10/26/09 7:21:58 PM Xcode[19072] Warning: Couldn't discover the 'clang' compiler's built-in search paths and preprocessor definitions for language dialect 'objective-c'. This may lead to indexing issues.
Compiler: /Developer/usr/bin/clang
Reason: clang version 1.0.1 (http://llvm.org/svn/llvm-project/cfe/tags/Apple/clang-24 exported)
Target: x86_64-apple-darwin10
clang: warning: not using the clang compiler for the 'armv6' architecture
I'm going to say that you tried to configure an iPhone Device build to use the Clang compiler, which is not yet supported for compilation. (It works for static analysis, but not for building).
Find the Compiler Version build setting and set it back to gcc 4.2.
I had this same problem and I was able to workaround it by:
Setting the target to be the iPhone simulator
Quit and relaunch Xcode
Rebuild the index
Clean and rebuild the simulator target
Maybe it's a bug in Xcode with iPhone device selected when a project is first opened.