Symbolicate Crash Log when App Name Contains Apostrophe and Space (Deployed App)

Question

I have an app on the App Store that is crashing. I have tried several of the solutions on SO to symbolicate my app, using at different times the Organizer, the Terminal, and Instruments. Nothing has worked so far - the lines in the reports from the methods in my app are never symbolicated, even when the lines for Apple methods are. After looking around for a while, it seems as though this might have something to do with the app name, which is along the lines of "Angie's List" - with both an apostrophe and a space. It is too late to change the app name now as it is live on the store. I haven't seen a solution to this anywhere and would appreciate a shove in the right direction.

Grippe

Answer 1

Usually the app name doesn't matter, unless there is a bug in the symbolication script which I doubt. Did you check if you have the correct dSYM available?

If you scroll down your latest crash log, check the 1st line below Binary Images, it will look like this

0x1000 -   0x24cfff +YourApp armv7  <f6012c517d783486ab53e45d948b92a2> /var/mobile/Applications/A8EC3C1F-44AF-169A-BC0E-FBBC0F04CDF5/YourApp.app/YourApp

f6012c517d783486ab53e45d948b92a2 is the UUID of the executable the caused the crash.

You can find the correct dSYM using the terminal as follows:

mdfind "com_apple_xcode_dsym_uuids == F6012C51-7D78-3486-AB53-E45D948B92A2"

The string F6012C51-7D78-3486-AB53-E45D948B92A2 is the above string reformatted to uppercase and 8-4-4-4-12 groups. I guess this command will not return anything.

If you have a dSYM (e.g. in an .xcarchive), you can check its UUID in the terminal as follows:

dwarfdump --uuid YourApp.app.dSYM 

If symbolication doesn't work automatically, you can try to do it manually by following the instructions posted here: iOS crash reports: atos not working as expected

If the application has special characters like spaces or apostrophe's in it, the default Apple toolchain will not be able to symbolicate it. The reason is that the tool otool, which being used in the toolchain, can't handle that. No matter how you pass the filename. So to fix this, you have to do the following:

1. Rename the dSYM package and remove all special chars, e.g. from My App's.app.dSYM to MyApps.app.dSYM
2. Open the content inside the package and navigate down to Contents/Resources/DWARF
3. Rename the file in there as you did above

Now try again. Best way to avoid all this: NEVER use special chars in your apps name. If you want the adjust the name that appears on the screen, use CFBundleDisplayName or the corresponding plist entries.

Pinkard

Thanks so much for your help. I'm in a pretty terrible place right now with this. The mdfind command DID return the location of the dSYM file. – Grippe

I feel like the name really has been a problem - I read on a few threads that people were having problems with spaces and apostrophes (separate threads) in their app name. And then I also wonder if I royally screwed up my app settings and there are, as you said above, errors in the dSYM. – Grippe

You can easily test this. Change all appearances of your apps name in the crash report file and remove the special chars from it. Make sure that the formatting keeps the same, e.g. by adding space at the end of the app name for the amount of chars you removed. And then try to symbolicate it again. – Pinkard

You think that the changes need to be made in the crash report file only? The thing is that the Apple methods for UIKit, Core Data, etc DO symbolicate correctly... I can give it a try in any case. I would also be really interested in knowing the correct app settings for all of the fields that involve symbols, for all build configurations - you seem like you know what you are talking about and I have just seen so much conflicting information on this. For example, I had Strip Debug Symbols During Copy Set to NO, but Strip Linked Product set to YES... just so confused – Grippe

I got the same results as before, with the Apple methods symbolicating correctly and those of my app.. not. I wasn't sure what to do with this line, as taking out the space and apostrophe without changing the name of the actual app file doesn't make too much sense: 0x3000 - 0x135fff + JacobsLadder armv7 <354c50d6ca0c3eebb39a7df07405bb3c> /var/mobile/Applications/02DEF31B-0435-4656-BA71-DEC01DCEDB84/Jacob's Ladder.app/Jacob's Ladder – Grippe

Given the string you pasted in here, there is no problem with spaces and special chars, since the application path is never used. The string right behind the address and before the architecture is what is being used for symbolication. Without error messages of the symbolication process it is impossible to know what is going wrong, if the UUID is really found. You could try calling atos directly with the dSYM you found with the mdfind command above. See #13575433 – Pinkard

I played with it for a while last night and got something with atos and only the dSYM, but the methods it gave me could not have been right - they were bizarre, totally unrelated and none of them called at any point NEAR startup of the app. Each of 6 logs - that looks exactly the same in the rest of the rest of the log - gave 5 completely random methods. So I feel that using atos with the dSYM, though it did yield some information, could not be right. Could it be that, while I did set Strip Debug Symbols During Copy to NO, I still mistakenly left Stripped Linked Product to YES? – Grippe

In theory anything could be, but that doesn't help. If you zip the dsym and the logs together and upload it somewhere, send me a link to it and I'll check it out. Everything else continuing wild guesses which doesn't help anyway. – Pinkard

let us continue this discussion in chat – Grippe

I did find the method where the crash occurs but still cannot replicate on various devices and iOS. Is there any way that I can find the line numbers using atos? – Grippe