How do I manually parse the symbol table based on the data provided by the Firebase Console

[hjlove]

[READ] Step 1: Are you in the right place?

[REQUIRED] Step 2: Describe your environment

[REQUIRED] Step 3: Describe the problem

Native Crash occurred without uploading the symbol table to Firebase.
The Firebase Console TXT column shows that the log is not being parsed properly by the addr2line script.
Below is the Native Crash log I copied from Firebase Crashlytics, How can I parse it correctly?

Crashed: Thread : SIGABRT 0x0000000000000000
#0 pc 0x7e2712d2a8 libc.so
#1 pc 0x7e2712d278 libc.so
#2 pc 0x7e2712d9e8 libc.so
#3 pc 0x7d30f3d480 libglipcore.so
#4 pc 0x7d2c1b0820 libglipcore.so
#5 pc 0x7da6555350 libart.so

Steps to reproduce:

Make a native crash without upload symbol

Relevant Code:

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[aguatno]

Thanks for reporting. I'm currently looking at this However, I have a few extra questions:

1. Were the steps done correctly: https://firebase.google.com/docs/crashlytics/ndk-reports?
2. Could you try updating to the latest Crashlytics SDK version or at least to version to get the latest updates and bug fixes? After that, please try again and see if you'll still encounter the issue.
3. Try Enable native symbol uploading in gradle: https://firebase.google.com/docs/crashlytics/ndk-reports#enable-symbol-uploading
4. Do you have external dependencies/libraries?

[hjlove]

Yes, answer your questions in the order in which they are asked

1. I have complete the configuration correctly, but I configured the nativeSymbolUploadEnabled as false
2. I have updated the latest version (BOM version: 26.7.0), but this problem still exists
3. This configuration is off
4. This is not configured.

Now the question is, how do we parse the symbol manually when we don't upload it to Firebase

[hjlove]

Hi, @kmandrika
Could you let me know about this issue going on?

[kmandrika]

Hi @hjlove,

Parsing the symbols manually is a bit tricky - we are going to make this process much easier in the future.

At this time, you need to open up Chrome Developer Tools when you are looking at a crash and select the "Network" tab. On that tab, select "XHR" and type "event" in the filter box & reload the page. You should see three entries. Select the entry that has the format "metrics:listSessionEventIds" and in the "Preview" pane, take note of the "sessionId". Next, select the entry that starts with the session id that you noted. In the "Preview" pane you should see a json payload that has a "binaryImages" field. This field will tell you the addresses that all binary images were loaded at when the crash occurred.

Take the address of each frame in your stack trace and find which binary image it is in. You can do this by finding the largest binary image address strictly lower than the frame's address and ensuring that the frame's address is within the binaryImage's baseAddress + size address range.

Once you find the appropriate binary image, subtracting the binary image's baseAddress from the frame's address will give you the offset into the binary image.

As you can see, it's a long process. In the future, we plan to display the txt version of the stack trace in a format is consumable by addr2line - stay tuned.

[google-oss-bot]

Hey @hjlove. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Since there haven't been any recent updates here, I am going to close this issue.

@hjlove if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.

[hjlove]

Thank you for your help. Could you please share when can support it?

[kmandrika]

Yes, definitely!