Missing symbol names when profiling IPhone application with Instruments - iphone

I am compiling an IPhone application via command line (so no XCode options involved) and 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 dsymutils to generate a .dSYM file but i have no clue how I'm supposed to use it so that failed aswell.
Any help will be greatly appreciated!

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:

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

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.

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.

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 :)

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?

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.

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.

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.

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.

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.

Related

Missing symbol names when profiling iPhone app in Instruments

I don't get any symbol names when I'm profiling my iPhone app.
It works in the simulator and when using Debug mode on the device, but not when using Release (as you should use when profiling). I know the dsym-file is generated for both release and debug, so that is not the problem.
I've tried the solution described here:
Missing symbol names when profiling IPhone application with Instruments
But when i choose "Re-Symbolicate Document" my app's name doesn't appear in the binary list (it does appear when using debug), so I can't try to manually add the dsym file.
I've also tried:
Adding and removing my Derived Data folder from Spotlight's Privacy list
Removing the app from the iPhone
Clean & Build before profiling
Removing the Derived Data folder before building and profiling
What can be the problem?
today i also missing symbols when profile on iPhone.
but i ever missing to find dsym file when i build a platform to analyse the crash reports. i remember i fix it by reindex spotlight.
so this time i do it to, because i find in resymbolicate documents, the instruments cannot find the dsym file for specfic udid. so i guess it is caused by system failed to find it with the help of spotlight(system always use mdfind command to find dsym file). if the spotlight failed to find, maybe the instrument cannot find dsym file too ..
so i go search the reindexing command:
sudo mdutil -E /Volumes/Macintosh\ HD
-E will tell the system to reindexing
this command to reindex the root disk. so it may costs some time.
after reindex, it's better for you to give a path to resymbolicate.
it's ok for me to make it work, if you have something don't understand, please let me known. thanks.

Symbolicate crash logs

Q1) How can I symbolicate the entire crash log file. I do have DYSM & APP files with me. Using ATOS command is tedious. My symbolicatecrash is not working.
Q2) If I forgot to capture the DYSM & APP files while generating a build, can I generate & use them after some time given that there is no modification done on that code after the build was generated. Will this be as good as capturing these file at the time of build generation?
A1) Just put DSYM, APP and crash files in one directory. Then open XCode Organizer->iPhone development->Device Logs, and just drag & drop crash log to a list. That's all, if you have a proper dsym file, crash log should appear with symbols in a list.
A2) If there are no modifications done on code, compiler and machine where build was generated, there's some chance. But I never succeed in my attempts to do this.
symbolicatecrash is a perl script that uses spotlight to locate the dSYM files that belong to the app that crashed. If you run symbolicatecrash with the -v (verbose) option you'll see something like:
Searching in Spotlight for dsym with UUID of ...
Running mdfind "com_apple_... == ..."
So, be sure that spotlight works, and the indexing for spotlight is active for the volume where your stuff is located, with the mdutil command: mdutil -s -a
If the volume your archived Apps are on is not indexed be sure to switch indexing on. (As root/sudo: mdutil -i on /Volumes/...)
You can also translate symbols manually using atos. Read more on my blog: http://www.dev-smart.com/archives/389

Analysing iPhone crash log

I got a crash log from a customer using my iPhone app and trying to get symbolic information out of, and failing spectacularly ... what I found online as instruction is this (to be executed on a Mac):
symbolicatecrash crash-log-file.crash symbol-file.dSYM > report-with-symbols.crash
crash-log-file.crash is the crash log obtained by the user via iTunes, a text file
symbol-file.dSYM is created by XCode each time you build the application and contains the symbols file (within a series of folders)
Unfortunately my attempts have all failed:
- with a version of symbolicatecrash I have (don't recall where & when I found it), the output is identical to the input file, without symbols
- with another version I found on my disk, I get this error message (note: I tried to point to the symbol file itself within the .dSYM tree - still no help):
/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash failedstart.crash ScanBizCards.app.dSYM/Contents/Resources/DWARF/ScanBizCards > crashwithsymbols
Can't understand the output from otool ( -> '\/Developer\/Platforms\/iPhoneOS.platform\/Developer\/usr\/bin\/otool -arch armv7 -l /Users/patrickq/Projects/icr/OCR/newOCR/build/Debug-iphonesimulator/ScanBizCards.app/ScanBizCards') at /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash line 301.
Help anyone?
I don't even mind doing the math myself for symbols but don't know how to open the symbols file ...
Patrick
symbolicatecrash is very buggy and try to do smart things to locate your binaries/dsym files using spotlight (mdfind). This line is the clue:
Can't understand the output from otool
( -> '\/Developer\/Platforms\/iPhoneOS.platform\/Developer\/usr\/bin\/otool
-arch armv7 -l
/.../build/Debug-iphonesimulator/ScanBizCards.app/ScanBizCards')
Apparently, it found one of your developement build product (for the simulator) and used it to try to symbolicate a crashreport generated on the device. And it failed miserably, of course.
The exact same problem occurred to two different people at our company. I haven't investigated how the problem happens. I imagine this is quite rare, otherwise, such an enormous bug would have already been fixed. For the moment, I have only this very crude workaround:
Remove all your build folder mentioning this executable name (in your case ScanBizCards.app)
Remove the application from the simulator (I mean, all the incarnations of the application in the various versions of the simulator, like in ~/Library/Application Support/iPhone Simulator/4.3, ~/Library/Application Support/iPhone Simulator/3.2, ...)
This leaves you with the archived applications only. This time, symbolicatecrash can't find a wrong version and eventually find the correct one.
If I ever reproduce the problem, I will take some time to debug this horrible perl script.
I hope that helps.
I have the same issue pointed out by Frederic. To more completely fix the issue, search for sub getSymbolPathFor_dsymUuid in the symbolicatecrash script, and change the following line:
my $cmd = "mdfind \"com_apple_xcode_dsym_uuids == $myuuid\"";
Add this parameter after mdfind:
-onlyin /path/to/your/app/bundles
and use the directory where you are storing your archived bundles. This way, it will always find the correct version of your app. If you want to be extra safe, scroll down a bit to where it says:
my #spotLightSearchForExecutable = `mdfind $executable.app'; # To cover the case where the DSYM's and .app are no located in the same location.
And add the -onlyin /path/to/your/app/bundles as well. This path is only used when, as the comment on the above line states, symbolicatecrash cannot find your .app in the same folder as your .DSYM. Hopefully, if you store them both in the same folder, this should never be run, but if you have any doubts, it's better to be safe and do this too.
It seems that you are running symbolicatecrash for iPhone simulator debug symbols, while you need to pass the path to symbols for iPhone device build
If you use the "Build and Archive" feature from Xcode to distribute the app (to Apple Store or the user), you can drag the crash log to the organizer and let the IDE do symbolication.
Remember, you must have the exact version of the app and .DSYM. Recompiling the app generates a different .DSYM and it will not work.

Unable to copy dSYM file into archive

Whenever I run 'build and archive' from XCode I get the following message:
Unable to copy dSYM file into archive.
Please make sure that your application has set the “Debug Information Format” build setting to “DWARF with dSYM File”.
I have checked my Debug format and it is set to the suggested value(DWARF with dSYM). Has anyone else ran into this issue, if so how did you fix it?
Try setting 'Generate Debug Symbols' to true in the build settings of the target you're trying to build and archive.
This solved the issue for me!
this worked for me ,i hope it help someone out there...
Goto to the build setting and search for "Generate debug symbol" and set it to Yes.
then search for debug information format in build setting and set "Debug information format" to "DWARF with dSYM file"
I just ran into the same problem, but I had an build script which removed the dSYM file before Xcode could. So it wasn't there and that was what Xcode was crying about.
I attached a screenshot, so perhaps the next one which runs into that problem can recover a bit quicker from that.
The 'Generate Debug Symbols' solution worked for me as well. After it worked once, I disabled the setting again, and I build & archive worked again, producing a file smaller by 700kb than the debug symbols enabled version. Not sure if this is actual savings after the app is on the app store, but it doesn't hurt!
That's how your build settings for both release and debug configuration should look like:
Generate Debug Symbols → Yes
Debug Information... → DWARF with DSYM
Deployment Postprocessing → YES
Strip Linked Product... → No
Strip Debug... → No
If there's still no luck, try check the Report Navigator.
The point is, dSYM file may be generated in another location, or not generated at all.
In my case, the dSYM file has not been generated, and there hasn't been a corresponding line that goes like "Generate Appname.dSYM ...in {path}"
But there's been Fabric installed, and it logged the fact of the dSYM file's absence:
Just filer the Report Navigator by "dSYM".
If dSYM is not generated in appropriate folder
Check environment variables, especially DWARF_DSYM_FOLDER_PATH and DWARF_DSYM_FILE_NAME.
To embed the dSYM within the app bundle, just set DWARF_DSYM_FOLDER_PATH to $(CONFIGURATION_BUILD_DIR)/$(EXECUTABLE_FOLDER_PATH) and DWARF_DSYM_FILE_NAME to $(EXECUTABLE_NAME).dSYM
Now the build should create dSYM for your target

Forcing code signing refresh in Xcode

In our environment, we share resources across multiple projects and platforms. When building for iPhone, only a subset of those resources are needed. Since that subset is still considerable, we have a manifest file listing what goes in, which limits the copy. We have our own Python script which does the copy, refreshing only the files which have changed.
I have made a Run Script Phase in Xcode to call that script, but I am having a few issues related to the Code Signing phase.
Since we use a separate manifest file, my Run Script Phase cannot specify any input/output file in the Xcode GUI: it varies depending on what is contained in directories at the time. The side effect of this is that Xcode doesn't strictly know what files will get copied (things happen "under the cover", so to speak).
The problem I have is that if I only modify resource files between builds, rebuilding my app will properly call my script, which copies the appropriate files, only Xcode won't rerun the Code Signing step, and won't re-copy my app to my device.
I found that odd, considering that my resource files are indeed listed in the <app_bundle>/_CodeSignature/CodeResources file, but it looks like Xcode determines rebuilds requirements independent of that (likely only files listed in the project file), which is understandable.
I tried playing tricks by touching my app bundle's directory, or the app's binary itself, but it doesn't quite work. Touching the app's bundle directory doesn't seem to do anything, while touching the binary will work, but NOT FOR THE CURRENT BUILD, only the subsequent one (since no input file requires recompilation, Xcode infers no new binary gets generated, but the next time, it will indeed detect that the binary has been touched, and redo both Code Signing and on).
Still, this is quite an imperfect workaround, because:
Having to build twice is error prone
My dSYM file will needlessly get regenerated
Does anyone know of any way to force the Code Signing step in Xcode (from a Run Script, or elsewhere)?
You can call codesign directly from the command line or a shell script, e.g.
codesign -f -s "iPhone Distribution" --entitlements Entitlements.xcent -vv location/MyApp.app/MyApp
Run man codesign to find out the usage.
You can discover all the internal commands run by viewing the detailed build output in Xcode. Select the Build tab, then click the little icon at the bottom left of that window pane - the one that looks like text (it is next to the warning icon). This will show the full build output in a new pane in Xcode.
I created a shell script calling codesign directly so I could re-sign an existing binary using a new certificate and provisioning profile (e.g. after updating some graphics in the binary).
This turned out to be really complicated as Xcode does some subtle stuff as part of its internal build processes (one example: Xcode embeds the provisioning profile in the resulting app binary, but in the process changes some of its values, e.g. the get-task-allow setting). That meant I had to write a tool to generate an appropriate .xcent file from the provisioning profile, depending on whether a Development/Distribution/App Store build is being done. Hopefully none of that will affect you...