Repository navigation
AArch64/Linux minidumps sometimes contain duplicate versions of the firefox binary module #161
Description
I was inspecting this crash which does not have symbols for functions within the firefox-esr executable and discovered that it's because the module appears to be duplicated within the module list. In particular the first entry has an empty debug id which prevents the stack walker from finding the appropriate symbol file. I've looked into the memory map and the executable mapping looks like this:
5590b80000-5590ba0000 r--p 00000000 08:02 634663 /usr/lib/firefox-esr/firefox-esr
5590baf000-5590c13000 r-xp 0001f000 08:02 634663 /usr/lib/firefox-esr/firefox-esr
5590c22000-5590c25000 r--p 00082000 08:02 634663 /usr/lib/firefox-esr/firefox-esr
5590c34000-5590c35000 rw-p 00084000 08:02 634663 /usr/lib/firefox-esr/firefox-esr
Notice how there are 0xf000-sized holes between the four mappings. It's unclear to me why the loader is laying out the executable in this way, but this is confusing the logic we have to merge mappings.
This issue can be seen as depending on issue #142 as we should be able to retrieve a proper mapping of the executable via the debugger rendez-vous instead of relying on the brittle logic to parse the maps file.
Activity
gabrielesvelto commentedon Oct 2, 2025
Note, these are users running Firefox ESR on a Raspberry Pi 4 with either Debian or Raspberry Pi OS. In both cases they appear to be using the Firefox ESR package that ships with Debian.