Xcode 4 Instruments doesn't show source lines

Question

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 source code for stack traces in Instruments, or is this a bug in Xcode 4?

So far, I've:

• Changed Debug Information Format from DWARF with dSYM File to DWARF.
• Changed Strip Debug Symbols During Copy from Yes to No.
• Changed the build scheme to use the Debug build instead of the Release build with Instruments.

Lovell

Answer 1

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.

1. Choose File → Re-Symbolicate Document…
2. 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."
3. Go back to Xcode. Control-click on your .app build product and choose "Show in Finder".
4. This will reveal the directory containing your binary as well as its dSYM file. Go back to Instruments, navigate to this directory, and select your dSYM file. The easiest way is to just drag the dSYM file straight from the Finder to the "Select dSYM" dialog in Instruments.
5. Finally, click "Symbolicate" in Instruments. You should now see symbols in the traces rather than hex offsets.

Comment

Thanks - this was helpful. And as a further note, if you can't see your "Library" folder on the finder or open file dialog, go to the terminal and execute: chflags nohidden ~/Library – Simoniac

+1000 ... Spotlight never works correctly with Xcode4 for me (too many bugs in Spotlight), and I've never found an effective workaround. You've saved me much pain! ... PS: Xcode needs to dump Spotlight dependence; spotlight is a terrible indexing solution, and Xcode has special needs - it shouldn't rely on an "unreliable" indexer! – Kirit

My binary isn't listed in the list (as per 2.) Has anyone else encountered this problem and found a solution? – Stonedeaf

This is the only way which works for me with XCode 4.6 (before XCode 4 it JUST WORKED -- but then broken at some point). Thank you very much, it's not convenient doing it every time, but still better then nothing!!! – Radiology

My binary isn't listed in the list either. Anybody else? Solutions? – Carom

@EnginKurutepe: I've unfortunately never encountered that. It'll probably be listed under the product name, not the Springboard name, if they're different for your app. Did you check under both? – Comment

My binary isn't listed on mine, either. I tried all the name types, even just scrolled through the unfiltered list... Definitely not there. About 10 minutes ago, it was working fine. Then all of a sudden, poof... – Recount

Answer 2

I had this issue today and solved it this way:

1. Edit scheme
2. Click on "Profile" on the left (this is the important step)
3. 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.

Posterity

Performance profiling in Release gives very different—and more useful—results than in Debug. Switching the Profile setting to Debug is not a good idea. – Courcy

This is the correct answer. Debug should profile in Debug. Release should profile in Release. – Buckwheat

The debug setting was what I had to do. I have been trying to resymbolicate but in release the debug symbols are stripped so symbolication is not possible. This is with my release settings (which are more or less the default, the only good answer. Thanks! – Vomer

Tried this, but unfortunately my call tree is still showing up only hexadecimal addresses. – Recount

Is there a way to enable this for the Release configuration too, through the target build settings? – Abundance

@rraallvv: Yes, all you really need is to match your build configuration with your profile configuration. – Posterity

Not sure why @OldPeculier's suggestion works, but it did for me. I expected the opposite, that Debug would be more likely to have the highest-fidelity information. – Caenogenesis

Answer 3

Try selecting a different code signing identity, i.e. provisioning profile, for the Release configuration.

Edraedrea

Worked for me, but it is completely random behaviour. – Offering

Release strips debug symbols in the default state. Symbolication appears to be not possible then. – Vomer

Answer 4

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

1. Ensure that you have compiled your code with debug flags enabled (e.g. -g3).
2. 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.

Mantinea

Answer 5

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.

Perineurium

There's a typo (mduitl vs mdutil) on the second line. Can't be fixed because changes on Stack Overflow must be 6+ chars. OMG! – Seldun

Answer 6

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.

Lovell

That sounds about right for Xcode 4. Things just mysteriously not work, and then, they do. I'm starting to think Apple built some serious AI into this IDE. – Fatling

Your comment made my day Alan : D – Hussite

Answer 7

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.

Ordinance

Answer 8

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.

Crestfallen