Repository navigation
Support libraries mapped from within APKs on Android #79
Description
We've started encountering minidumps coming from Android builds of Firefox where the shared libraries have been mapped directly from an APK (which is just a ZIP file, so they're probably stored uncompressed). The relevant mappings look like this:
7e042700c000-7e042700e000 r--p 00001000 fd:20 7315 /data/app/org.mozilla.geckoview.test_runner-1/split_config.x86_64.apk
7e042700f000-7e042707e000 r-xp 00002000 fd:20 7315 /data/app/org.mozilla.geckoview.test_runner-1/split_config.x86_64.apk
7e042707e000-7e04270af000 r--p 00071000 fd:20 7315 /data/app/org.mozilla.geckoview.test_runner-1/split_config.x86_64.apk
7e04270b0000-7e04270b2000 r--p 000a2000 fd:20 7315 /data/app/org.mozilla.geckoview.test_runner-1/split_config.x86_64.apk
7e04270b2000-7e04270b3000 rw-p 000a4000 fd:20 7315 /data/app/org.mozilla.geckoview.test_runner-1/split_config.x86_64.apk
Since we record the module name we find in the mappings the minidumps are unusable, as we can't symbolicate them.
We look for the SONAME in the mapped ELF file so we should be finding it, but chances are that we are failing to open the underlying file here.
So this could be related to issue #71, because we'd be certainly capable of finding the SONAME within the crashed process' memory. If we switch reading the build ID from there, reading the SONAME would be a trivial addition.
Activity
gabrielesvelto commentedon Mar 7, 2024
This is how these crashes look like in the wild
Read ELF SONAMEs directly from process memory when possible.
Read ELF SONAMEs directly from process memory when possible.