If the dSYM is not uploaded to New Relic, mobile crash reports cannot be symbolicated. You can upload dSYMs manually or directly through the New Relic Mobile UI. However, every build of an application will create a new dSYM, and it can be difficult managing which dSYM is attributed to which app build.
In this situation, you can use the Build UUID identifier to:
- Identify a unique build of an application.
- Find which dSYM can be used to symbolicate a crash.
View the Build UUID
An application may have more than one Build UUID, one attributed for each CPU architecture the application is built. The Build UUID is also stored within the associated dSYM and can be extracted to identify the dSYM.
New Relic crash reports also contain the Build UUID of the crashing application. To view the Build UUID:
- Go to rpm.newrelic.com/mobile > (select an app) > Crashes > Crash Analysis.
- From the Crash list table, select any row.
- From the selected crash report's Crash Details page, look for the
App Image Uuidon the attribute list.
App Image Uuid is not on the selected crash report's attributes list:
- Export the crash details.
- Look for the Build UUID in the Binary images section of the exported crash report.
Use the Build UUID extracted from the crash details to find the missing dSYM.
Binary images example
Here is an example of the Binary images section from an exported crash report. This section lists the Build UUID for every dynamically-linked library included in the application, as well as the Build UUID for the main application.
In this example, the main application is
New Relic. Its Build UUID is
117667e7b8d230cb8a908906c64e0227. This is the identifier you can use to find the associated dSYM.
Binary Images: 0xb1000 - 0x30d000 New Relic armv7 <117667e7b8d230cb8a908906c64e0227> /var/containers/Bundle/Application/New Relic.app/New Relic 0x22290000 - 0x22292000 libSystem.B.dylib armv7 <39d6d6f7c2ac3de8bb29c40a1b66368a> /usr/lib/libSystem.B.dylib 0x22292000 - 0x222de000 libc++.1.dylib armv7 <017dba6c16b63f9ebecb9ddd0d0a4520> /usr/lib/libc++.1.dylib 0x222de000 - 0x222f9000 libc++abi.dylib armv7 <d32373f6c2153a509f6603750d213ffb> /usr/lib/libc++abi.dylib 0x222fc000 - 0x22667000 libobjc.A.dylib armv7 <94f6d325c1843f45b3a439b86fc9de15> /usr/lib/libobjc.A.dylib 0x22667000 - 0x2266c000 libcache.dylib armv7 <8009f99fb892331dbcb61cd740ff0f43> /usr/lib/system/libcache.dylib 0x2266c000 - 0x22676000 libcommonCrypto.dylib armv7 <f6db318471d732d39918ef36bde65cb7> /usr/lib/system/libcommonCrypto.dylib 0x22676000 - 0x2267c000 libcompiler_rt.dylib armv7 <cfa3ca12d6c2383abcaf3c8541e9b86c> /usr/lib/system/libcompiler_rt.dylib 0x2267c000 - 0x22683000 libcopyfile.dylib armv7 <d2b06020c3693c7b9d179434f8115ba0> /usr/lib/system/libcopyfile.dylib 0x22683000 - 0x226d3000 libcorecrypto.dylib armv7 <181437f8d9e53277ace439de8b3fd1ad> /usr/lib/system/libcorecrypto.dylib 0x226d3000 - 0x2271d000 libdispatch.dylib armv7 <bbb4bba2176039ab95a59d7a56f6eff8> /usr/lib/system/libdispatch.dylib
Find and resymbolicate the dSYM
To find a dSYM's Build UUID of a dSYM: use
dwarfdump with the following terminal command:
dwarfdump --uuid <path-to-dSYM>
In the following example, the New Relic dSYM returns two Build UUIDs, one each for
ARMv7 Build UUID matches the Build UUID of the missing crash example:
> dwarfdump --uuid ./New\ Relic.app.dSYM/Contents/Resources/DWARF/New\ Relic UUID: 117667E7-B8D2-30CB-8A90-8906C64E0227 (armv7) ./New Relic.app.dSYM/Contents/Resources/DWARF/New Relic UUID: B1A8C6EE-02B9-3C55-AEE7-308521873107 (arm64) ./New Relic.app.dSYM/Contents/Resources/DWARF/New Relic
To symbolicate the unsymbolicated crashes, follow the instructions to manually upload the dSYM.