Symbolicating crash logs in XCode 4.3.2

Question

Whenever a crash happens on my application, the crash logs are shown in symbolicated form inside the organizer. Now the problem is that all memory addresses that points to iOS classes are getting symbolicated fine but memory addresses of my application classes are not getting symbolicated. Which XCode project property do I need to set to enable them.

These are the current build settings which enabled symbolication of iOS classes. I am using XCode 4.3.2.

Concordant

By the way, do you happen to have Xcode 3.x installed on the same system? – Diaphony

@Diaphony why are you asking for that? – Concerto

It used to cause some problems with symbolicating, from what I heard. And my problems too disappeared along the same time, when I finally got rid of 3.x. Might have been a coincidence, though. – Diaphony

Have you found an answer? I have the same problem. It used to work well in XCode 4.1 – Quit

Answer 1

Have you turned off spotlight? symbolicatecrash uses spotlight to find the binaries and dsym files, so if you've turned off spotlight then it won't be able to find them. Anyway, here is how to convert a hex stacktrace address into a line number:

[1] Find the .dSym file by going to XCode->Organizer, clicking on archives, then right click on the archive, and cd into this directory (you can just drag the folder into a shell window).

[2] cd into the dSYMs directory.

[3] run the dwarfdump command to translate the hex address into a line number in your code:

dwarfdump --arch armv7 myApp.dSYM --lookup 0xaabbccdd | grep 'Line table'

Acred

Answer 2

Strip Debug Symbols During Copy: Should be YES on non debug configuration builds, since it will blow up your app binary 30-50%

Debug Information Format: Should be DWARF with dSYM File for all configurations, to be able to symbolicate your symbols from any binary.

Now I guess that you are trying this on debug builds, on builds that are not the latest results of the build command in Xcode. You have to remember that every time you run the build command, a new executable and a new dSYM package is being generated, and the previous one gets overridden! (Except if you use the Archive feature)

The symbolication script parses the UUID from the crash report of your app and searches the corresponding .app AND .app.dSYM bundle via spotlight. So if either spotlight is not indexing the target path or the binaries are replaced by another build run, it won't be able to symbolicate the apps symbols.

Messeigneurs

How can I add a set of symbols to XCode, in order to symbolicate corresponding crash logs? – Masterstroke

The dSYM of that build has to be available and indexed by Spotlight. Then it should be found. So. e.g. by archiving beta versions and app store releases, you should be fine. Debug builds are not archived, and every new build will overwrite the previous dSYM. And that will be different, even though you did not change a single line of code. – Messeigneurs

Answer 3

Try setting Deployment postprocessing to NO.

DEPLOYMENT_POSTPROCESSING. Activating this setting indicates that binaries should be stripped and file mode, owner, and group information should be set to standard values.

Diaphony

Setting up DEPLOYMENT_POSTPROCESSING to NO does not solves the issue. – Concordant

Answer 4

It seems that xcode uses last archived build .dsym file to symbolicate your logs (even in debug), so try archiving your app.

After archiving your app Re-Symbolicate your crash reports.

It worked for me.

Enrico

This is not correct! The symbolication process uses Spotlight to search to matching dSYM according to the apps UUID that generated the crash report. Each build will result in a new UUID. Archiving makes sure that you will have the correct dSYM for those builds. But e.g. when creating debug builds, each new build will overwrite the previous one and symbolication of crashes from earlier builds is not possible any more. – Messeigneurs