I've just started playing with Xcode 4, and found that, no matter how I setup debugging symbols in the project, Instruments refuses to display source lines for stack trace items that correspond to my code. In only shows hex offsets and identifies my executable as the owning module. Turning on "Source Location" draws a blank too. This occurs even for the skeleton OpenGL ES project generated by Xcode (File → New → New Project... → iOS → Application → OpenGL ES Application).
This problem only occurs in Instruments (I've tried CPU and OpenGL tracing so far). Gdb picks up debug symbols just fine.
Do I have to do something special to see the sou开发者_如何学Pythonrce code for stack traces in Instruments, or is this a bug in Xcode 4?
So far, I've:
- Changed
Debug Information Format
fromDWARF with dSYM File
toDWARF
. - Changed
Strip Debug Symbols During Copy
fromYes
toNo
. - Changed the build scheme to use the Debug build instead of the Release build with Instruments.
The other answers are good long-term fixes. If you'd rather not wait for Spotlight to rebuild its index and just need to get symbols for one Instruments session, you can ask Instruments to symbolicate the current session.
- Choose File → Re-Symbolicate Document…
- Locate your binary in the list that appears. It should be the same name you see on the Springboard. Select your binary and click "Locate."
- Go back to Xcode. Control-click on your .app build product and choose "Show in Finder".
- This will reveal the directory containing your binary as well as its
dSYM
file. Go back to Instruments, navigate to this directory, and select yourdSYM
file. The easiest way is to just drag thedSYM
file straight from the Finder to the "Select dSYM" dialog in Instruments. - Finally, click "Symbolicate" in Instruments. You should now see symbols in the traces rather than hex offsets.
I had this issue today and solved it this way:
- Edit scheme
- Click on "Profile" on the left (this is the important step)
- Change Build Configuration to Debug
That should do it. Note that for whatever reason, the build target is not set to the same build configuration as the profile target and this has tripped me up more than a time or two.
Try selecting a different code signing identity, i.e. provisioning profile, for the Release configuration.
I found out what the issue was, as I had the exact same problem.
The answer comes from: Missing symbol names when profiling IPhone application with Instruments
- Ensure that you have compiled your code with debug flags enabled (e.g.
-g3
). - Execute
dsymutil
on your binary/dynamic library that you want to be able to access the debug information for.
This generates a dSYM bundle folder, and when indexed by Spotlight the debug information necessary is made available to Instruments.
I suppose in your case, it took some time before Spotlight had things indexed - and when it had, then things magically worked out.
It just started working; no rhyme or reason.
I have spent the last half-hour trying to get it to fail again, in the hope of providing a more useful answer here, but I can't, even after recreating the skeleton OpenGL program from scratch, retracing all of my steps.
I did open the symbolicatecrash script in emacs (It has been implicated elsewhere, wrt this kind of problem), and it started working after I did this. But at no point did I change or save it.
It's a mystery.
One reason for instruments having no symbols could be that Spotlight cannot find the dSYM file. So your change from DWARF with dSYM
to DWARF
is not a good idea. You should change it back since without a dSYM file, you won't get symbols anyway (at least this seems to be the case for Snow Leopard, I have seen reports that some people also got symbols without dSYM files, however, all those people were using Lion). After making the change, make sure you create a clean build (sometimes Xcode fails to generate the dSYM file on my system for non-clean builds).
If you still get no symbols after all that, something is wrong with your Spotlight database. Try adding the folder that contains the dSYM files after a build to the list of folders Spotlight shall not index and then remove it again from that list. This causes Spotlight to reindex the files.
If this also doesn't help, maybe your Spotlight index is completely corrupted. In that case, try the following on a Terminal:
sudo mdutil -i off /
sudo mdutil -E /
sudo mdutil -i on /
This causes Spotlight to first stop indexing your main hard drive, then delete all index data collected in the past and then start reindexing it. The lines above assume that your dSYM files are located on the main hard drive (and not on any other hard drive or network volume, otherwise you must replace '/' with the appropriate mount point of that volume). Give Spotlight some time to reindex before you try again.
In newer versions of Instruments (I have 5.1.1 (55045)
), you can add additional paths to be searched for the dSYMs and source code
Open up Instruments' Preferences, then click the "dSYMs And Paths" tab.
Then add your path to the list.
Here's my environment...
- XCode 8.2
- Mac OS v10.12 Sierra
I had the same problem running in the simulator, and it was driving me nuts because ALL the standard go-to fixes were not working.
What did it for me was plugging my iPad into the MacBook and running an instruments session against said app on my plugged in iPad. Instruments properly symbolicated my app when running on the iPad, and then continued to work when I disconnected the iPad and ran instruments later in the simulator.
I suspect it had something to do with updating my project to use the following...
- libsqlite3.tbd instead of libsqlite3.dylib
- libstdc++.6.tbd instead of libstdc++.dylib
I don't know why that would be the case, but that was the ONLY project change I had made before my symbols were lost in Instruments.
精彩评论