Crash logs are not parsed in the MAS console - Mobile Platform as a Service

The Mobile Analysis Service (MAS) module supports uploading crash logs to help you monitor and capture crash problems on the client. The crash log of an Android application automatically symbolicates the call stack of the location where the crash occurs before upload. The symbolical call stack can be used to directly locate the crashed code. However, you need to upload a symbol table on the console for an iOS platform.

To solve the problem, you must understand what a symbol table is and why it is required.

What is a symbol table?
A symbol table stores the mapping relationship between the memory addresses and the function names and line numbers in codes.

Why is a symbol table required?

The crash log uploaded by an iOS application records the call stack information as memory addresses. You cannot view the information of corresponding call stacks in an intuitive way. To locate the crash in codes, the mPaaS server uses the symbol table to parse the iOS crash log and restore the program stacks. For example:

Before parsing:

  18  NebulaTest                        0x00000001030f6b7c 0x104ad4000 + 9282380
  19  NebulaTest                        0x00000001030f6ed4 0x104ad4000 + 9283236
  20  NebulaTest                        0x00000001030f6d0c 0x104ad4000 + 9282780
  21  NebulaTest                        0x00000001030f6ed4 0x104ad4000 + 9283236
  22  NebulaTest                        0x00000001030f6d0c 0x104ad4000 + 9282780

After parsing:

  18  NebulaTest                        0x00000001030f6b7c -[DTJsonEncoder encodeObject:ofClass:recusive:] + 424
  19  NebulaTest                        0x00000001030f6ed4 -[DTJsonEncoder encodeObject:] + 280
  20  NebulaTest                        0x00000001030f6d0c -[DTJsonEncoder encodeObject:ofClass:recusive:] + 824
  21  NebulaTest                        0x00000001030f6ed4 -[DTJsonEncoder encodeObject:] + 280
  22  NebulaTest                        0x00000001030f6d0c -[DTJsonEncoder encodeObject:ofClass:recusive:] + 824

The iOS project queries the dSYM symbol table file

In release compiling mode, XCode generates a dSYM file by default. In debug compiling mode, additional configurations are required:

In the iOS project, select Build Settings > Code Generation > Generate Debug Symbols > Yes.
Select Build Settings > Build Option > Debug Information Format > DWARF with dSYM File.
After compiling is complete, open the folder where the application is located:
The dSYM symbol table file is generated in the same folder.

Upload the symbol table on the mPaaS console

After releasing an application in Apple's App Store, you must add a release task for the corresponding version on the mPaaS console. After the release task is added, upload the corresponding symbol table file.

When this version generates a crash log, you can view the parsed crash log on the mPaaS console if all configurations are correct.

Note

If the console fails to parse the crash log of an iOS application after the iOS project uploads the symbol table, you must check locally whether the symbol table can be used to parse a crash log manually.

If the crash log is incompletely or incorrectly parsed, check whether the symbol table matches the actual application version. You must manage and back up the dSYM file of the release version of the symbol table and avoid losing the symbol table.