Search code examples
iosxcodecrash-reports

Empty dSYM folder in Xcode archive

I've Googled this extensively, and either the situation someone's experiencing involves a different Xcode version (and therefore different build options), or a presence of a dSYM file.

So, here's the situation. I received a crash report through Xcode. It's just memory addresses. Trying to open it in project gives me the same memory addresses. Thought about manual symbolication but for that I need my dSYM file corresponding to the archive I built. But when I 'Show package contents' for the archive I built in finder, its dSYM folder is empty.

My Xcode settings at the time of archiving were:

DEBUG_INFORMATION_FORMAT: DWARF with dSYM File

STRIP_INSTALLED_PRODUCT: Yes Switching to No makes no difference.

DEPLOYMENT_POSTPROCESSING: No Switching to Yes makes no difference.

Also, I selected 'Include symbols' when uploading the archive to iTunes Connect.

The process for deployment with Apple is confusing-as-hell enough, without having to worry that when a crash does happen, the resport is in fact readable!

So my questions are:

1) Why was my archive missing a dSYM file?

2) If the dSYM file would've been generated, where could it be?

3) If I really do not have a dSYM file, can I still somehow get human-readable symbol names? I've got the original archive I uploaded and access to source code for that build.

3a) If I Product>Archive again (and assuming this time a dSYM does get generated), can I use this dSYM file instead? Or will it have a different UUID, causing it to be incompatible with the crash log cause...well...Apple?

Xcode version: 6.4

Here's what my crash log looks like in Xcode Organizer: enter image description here

Thanks.

EDIT:

I upgraded to Xcode 7.3 before trying this but it may also work for version 6.

The solution to question (1) is to set the following in project build settings:

GCC_GENERATE_DEBUGGING_SYMBOLS

Solution

  • For question 1), I also don't know. It may be a bug of Xcode. You can archive
    the same code again, then generate a same dSYM file.

    For question 2), you can search 'dSYM' in the folder '~/Library', because 'dSYM' file output in there generally. If not found, try searching it in the entire disk.

    For question 3), you must have the system library symbol file that the crash log listed in 'Binary Images' section. You can find it in '~/Library/Developer/Xcode/iOS DeviceSupport'. If not found, you can connect an iPhone with the same OS version showed in the crash log to Xcode. After Xcode finished processing it, the system library symbol file of the iPhone can be copied to the folder. Then, you can re-symbolicate the crash log.

    For question 3a), For the same app code, different Archive may be have a different dSYM file(UUID). If you use it to symbolicate the crash log, the symbolicated crash line is very close to the real crash line, so this can also help you to infer the real cause of crash.

    From your screenshot, there only one line from your app code not be symbolicated. Now, you can generate the dSYM file of your app through using the app code which causes the crash to archive again. After you generate the dSYM file, use command line dwarfdump -u yourApp.app.dSYM to get UUID of it,Then check the uuid if contained in the first line of 'Binary images''. If NO, you can modify the UUID in the first line of 'Binary images'' to same as the new UUID which got from dwarfdump -u XXX.dSYM, Note the cpu architecture. Finish this, you can re-symbolicate the crash log in Xcode, or use command line symbolicatecrash crashreport.crash yourApp.app.dSYM. Note, you must guarantee the version of your app code same as version in the crash log, if not, the result is unbelievable.