Missing symbol names when profiling IPhone application with Instruments

Question

I am compiling an iPhone application via command line (so no Xcode options involved) however I am unable to get my symbol names to show when profiling with Instruments.

I have tried several flags such as -gdawrf-2 and -g without any success. I have also tried using dsymutil to generate a .dSYM file but I have no clue how I'm supposed to use it so that failed as well.

Piraeus

I created a "Profile" build configuration to deal with this issue. See my answer to a similar Stackoverflow question. – Niobous

Answer 1

How Instruments obtains debug information:

Instruments obtains debug info from a .dSYM file which is normally generated automatically by XCode when setting Debug Information Format to DWARF with dSYM File combined with a checkmark in the Generate Debug Symbols option box. Setting these options will add an extra step to the XCode build process and generate a dSYM file after the application has been compiled. Every dSYM is built with a UUID that corresponds to a UUID in a Mach-O section in the binary that it's derived from. A Spotlight importer indexes the UUIDs of every dSym file that is in a Spotlight-accessible location on your Mac. Therefore SPOTLIGHT does all the black magic and is responsible of making the link between the .app you are running and its corresponding .dSYM file.

How to generate debug information and dSYM file without XCode:

Make sure you are compilig with –gdwarf-2 and -g flags. (Other flag combinations might work)

-g Produce debugging information in the operating system's native format (stabs, COFF , XCOFF , or DWARF 2). GDB can work with this debugging information. On most systems that use stabs format, -g enables use of extra debugging information that only GDB can use; this extra information makes debugging work better in GDB but will probably make other debuggers crash or refuse to read the program. If you want to control for certain whether to generate the extra information, use -gstabs+, -gstabs, -gxcoff+, -gxcoff, or -gvms (see below). GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.
Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs.

-gdwarf-2 Produce debugging information in DWARF version 2 format (if that is supported). This is the format used by DBX on IRIX 6. With this option, GCC uses features of DWARF version 3 when they are useful; version 3 is upward compatible with version 2, but may still cause problems for older debuggers.

Generate a dSYM file using dsymutil. If the tool isn't recognized in command line, use spotlight to find it. IMPORTANT: Place .app file on your mac HD before you generate the dSYM if you are working on a networked drive.

dsymutil MyApp.app/MyApp -o MyApp.app.dSYM

Place the .dSYM file on the mac's local drive and run Instruments as you normally would.

Resettig spotlight's indexing:

If symbols aren't shown, it might be because spotligh is bugged. You can try reseting spotlight's indexing by adding your folder containing the dSYM file (or even your drive) to the “Prevent spotlight from searching these locations” in the spotlight preferences and then removing it right away.

Piraeus

Thank you. I'd previously excluded my Xcode DerivedData folder from the Spotlight index to help Spotlight find the correct .dsym to symbolicate crash logs. Removing that did the trick. – Montpelier

Though it may require Finder to be able to show hidden folders, and need to use drag-drop to be able to temporarily add the folder into Un-indexed folder list, it did work for me nicely right after removing it, to be indexed again – Collier

This happened to us because we changed the Debug Information Format from "DWARF with dSYM File" to "DWARF" for performance reasons. We have the format set to "DWARF with dSYM File" in another scheme. So we just have to change schemes whenever we want to profile. – Dicho

Answer 2

I Changed my project settings to not include the dSYM file while building:

Changing it to include the dSYM File helped the profiler desymbolize the symbols and fixed my issue:

Acquiescence

I don't think this answers the question, since your screenshots are from Xcode and the question deliberately precludes Xcode (@mac-twist is using the command line), but I'm using Xcode and had this problem, Google directed me to this question, and your suggestion worked for me - thanks. – Ceporah

I have the same issue and using instruments and Xcode with debug build option. this worked for me. Xcode 7.3.1 & iOS 9.3.4 – Sari

Very interesting that Debug defaults to no dSYM File inclusion! :/ Thanks for sharing this. Profiling now shows all symbols! :) – Poppycock

@Jona: The downside of generating dSYM files is that building take significantly longer— this is why Debug build don't include them by default, since you typically want to be able to build and run quickly. – Mathi

I guess this is why by default Xcode will make a 'release' build when you choose "Build for profiling" – Doit

This solved my problem for my own symbols, but what about system libraries like AppKit and Foundation? Is there a way to symbolicate them, so my instruments stack traces are less opaque? – Expiratory

Answer 3

I was still having issues with this.

My issue was I was able to see the dSYM file being generated, but Instruments wasn't picking it up.

To fix this, do the following:

1. Locate your dSYM file (should be in ~/Library/Developer/DerivedData/APP_NAME-XXXXXXX/Build/Products/[BUILD_TYPE]-[DEVICE-TYPE]/
2. With Instruments stopped, click on File -> Re-Symbolicate Document
3. Scroll down to the entry with your app name
4. Click "Locate" and choose the folder from step 1
5. Click the Start button to begin profiling

Hannis

I like this solution since it doesn't rely on Spotlight to work. It was also the only one which fixed this issue for me. Thanks! – Slattern

But now I have to do this repeatedly, with each run. Any way to make it stick? – Barbed

I got an error when trying to re-symbolicate (something about how the dSYM file and the app didn't have matching UUID's), so I just deleted all files in the [BUILD_TYPE]-[DEVICE-TYPE]/ folder (see step 1 above) and repeated the process, and then it worked. Yeah! – Walleyed

Oh and also, with the latest version of XCode, DerivatedData is in your project's directory, NOT in ~/Library. – Walleyed

@k06a - did you figure out how to get your app in the list? – Holsworth

@Holsworth I've just changed signature in target from distribution to developer and it helps. – Harriette

@Harriette Can you elaborate on that please? – Decathlon

This worked for me, but on Xcode 7 I didn't have to locate the dSYM. I just had to go to File > Symbols and hit Done and it fixed it. If you do need to locate the dSYM, DerivedData is now at ~/Library/Developer/Xcode/DerivedData. – Dicho

Answer 4

In Xcode 4.5 you can choose to Profile from Debug or Release builds. Release defaults to stripping the symbols when copied to the device. It's very easy to switch to the Debug configuration for profiling without breaking your release configuration. To do that, select Product -> Edit Scheme from the XCode menu. Select "Profile" from the list of schemes that comes up, and then select the correct Build Configuration for that.

Or you could make a separate release/profile configuration and use that in your Profile section of your scheme. How to add a separate build configuration is described in the XCode User Guide.

Incoordination

Also if you are building for profiling, definitely check "Profile" scheme that it has assigned some build configuration generating debug symbols like Debug! (was my problem) – Dallon

Answer 5

With Xcode 6 Instruments you can provide dSYM file as follow:

• File -> Symbols... menu (when profiling is stopped)
• select your app and press Locate button
• select path which contains dSYM (usually ~/Library/Developer/DerivedData/APP_NAME-XXXXXXX/Build/Products/[BUILD_CONFIGURATION]-[TARGET_PLATFORM]/). Tip: You can copy this path from terminal and use OS X shortcut ⌘+SHIFT+G in dialog.

Also Instruments will ask you if it should use selected path to try load dSYM for this app in the future. Answer Yes :)

Insatiate

Answer 6

Spent three days trying to figure this out for Xcode 7.1/7.3...

Changing the deployment target to the latest version (9.3 at the time) fixed this issue for me. My company targets 7.0 so I will probably have to create a custom Scheme for profiling the code in Instruments to avoid having to change the target (or forgetting to change the target) when we do a production release.

Seems like it's probably a bug if dSYMs fail to work based on the deployment target?

Styrax

+1 for this answer, I've basically tried everything I could find relating to dSYM files, spotlight, build schemes, debug symbol formats, etc. Nothing fixed anything, but switching to the latest deployment target the symbols were found immediately. Now that I think about it, I think this probably also explains why the debug navigator never showed any memory or CPU statistics while running with a lower deployment target. Way to go Apple for not popping up some kind of warning or whatever :-/ – Upcast

Answer 7

In my experience, this is usually because "Profile" has been called before the most recently modified version of the app has been installed on the target device.

Try running the app on the device/target, then calling "Profile" again after it has been reinstalled.

Tientiena

Also for my user-story, I guess you can attach proper symbols again. but quitting and making instruments re-open obtained the symbols (after I have ensured I keep symbols in release) – Unquote

Answer 8

The problem is that spotlight cannot find the .dSYM files. This is because Apple changed the location of the DerivedData folder. The DerivedData now goes in ~/Library

Spotlight will not index ~/Library and as far as I have been able to establish, cannot be made to index it either (e.g. mdimport is ignored).

A work around to get symbols in your profiler, is to simply copy the data outside ~/Library e.g. your home directory will do fine.

I used this command line:

$ cp -r ~/Library/Developer/Xcode/DerivedData/AppName-xxxxxxxxxxx/Build/Products/Release-iphoneos/ ~/

When you kill your profiler, and start a new profile run, you will see that the symbols are available again.

Neuralgia

Answer 9

Check the build log and make sure that your -g switch is getting through to the compiler - it's easy to get this wrong when changing settings at the project and/or target levels for different build configurations etc.

Flop

The flag is there, i quadruple checked. – Piraeus

Answer 10

Another work around in the version of Instruments that comes with Xcode 4 is to use the Re-Symbolicate Document menu item under the File menu for Instruments. This menu item to allows you to use the symbols located in the .dSYM file in ~/Library/... directory.

Hemichordate

Answer 11

I got this problem because the XCode project was on a network share where Spotlight wouldn't find the dSYM files. Make sure it's on the local drive.

Gasolier