crash-stats no longer follows symbolic links to identify module filenames
Categories
(Socorro :: Processor, defect)
Tracking
(Not tracked)
People
(Reporter: karlt, Unassigned)
References
Details
(Keywords: regression)
e.g. https://crash-stats.mozilla.org/report/index/4ffc6620-fdee-4ab2-b541-a2c140240220#tab-modules
Expected: Filename or Debug Filename libexpat.so.1.8.10.
Actual: Filename and Debug Filename both libexpat.so.1.
Version information is still kind of available in the Debug Identifier, but this requires guessing the library version, finding a library built with exactly the same compiler, options, and dependencies, and running dump_syms on the library.
Canonical full paths (/usr/lib64/libexpat.so.1.8.10) are in the .dmp files, so this appears to be a regression in the server. It regressed sometime before bug 1824634 comment 3.
|
||
Comment 1•2 years ago
|
||
I don't think it's an issue with the server. The module list in the minidump contains the SONAME of the library which is libexpat.so.1, we've been storing things in minidumps like that for a while because it matches the way we dump symbols and both need to agree on the module name for the system to work. We've also been trying on surfacing the version number of a library as encoded in the mapping (which we also have in the minidump), see bug 1847098 which will land very soon.
|
||
Comment 2•2 years ago
|
||
To comment on the bug summary assertion, if it is a regression, then it's either something that changed in dump_syms which generates the symbols files at build time or it's something that changed in rust-minidump which processes dump files and generates the minidump output that the Modules tab renders. This isn't something that we changed in Socorro (processor or webapp).
|
Reporter | |
Comment 3•2 years ago
|
||
Thanks! The changes for bug 1847098 look like they'll be useful.
Perhaps this might even be a regression from switching to rust-minidump.
Description
•