some linux crashes missing symbolication
Categories
(Toolkit :: Crash Reporting, defect)
Tracking
()
People
(Reporter: jcristau, Unassigned)
References
Details
There's an unusual number of crashes on yesterday's nightly with libxul.so@... signatures: https://crash-stats.mozilla.com/search/?release_channel=nightly&build_id=20180222101929&cpu_arch=amd64&signature=~libxul.so%40&product=Firefox&version=60.0a1&platform=Linux&date=%3E%3D2018-02-16T12%3A40%3A00.000Z&date=%3C2018-02-23T12%3A40%3A17.000Z&_sort=-date&_facets=url&_facets=user_comments&_facets=install_time&_facets=version&_facets=address&_facets=moz_crash_reason&_facets=reason&_facets=build_id&_facets=platform_pretty_version&_facets=signature&_facets=useragent_locale&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform The symbols are available on the symbol server, and calixte tells me he's able to symbolicate these addresses: 11:36 < calixte> fyi: addr2line -f -C -e ./libxul.so.dbg 0x203fc00 11:36 < calixte> mozilla::FrameLayerBuilder::GetOldLayerForFrame(nsIFrame*, unsigned int, mozilla::DisplayItemData*)
Comment 1•7 years ago
|
||
:ted, do you have any idea here ? Could it be related to bug 1440282 ?
Comment 2•6 years ago
|
||
Hello Will - Is this something you can help with? Also can we get someone to be triage owner of this component? Thanks.
Comment 3•6 years ago
|
||
Is this an ongoing issue that spans multiple builds or is it isolated to the build in the url in the description? Is there a better url that shows the crashes having problems? That url only shows 23 which doesn't seem unusual to me given we get tens of thousands of crashes a day.
Comment 4•6 years ago
|
||
(In reply to Calixte Denizet (:calixte) from comment #1) > :ted, do you have any idea here ? Could it be related to bug 1440282 ? I looked into this briefly and we do seem to have valid symbols for these crashes but the .sym files are missing functions for these addresses. I didn't find time to look into it more deeply. It is entirely possible that it's related to that issue, or potentially the same issue.
Comment 5•6 years ago
|
||
This is preventing us from properly bucketing crashes found by our fuzzers.
Updated•6 years ago
|
Updated•6 years ago
|
Comment 7•6 years ago
|
||
I haven't looked at the crashes but if comment 4 is true and only some functions are missing then this might be an instance of bug 1440282. In my first quick test roughly ~8% of the functions are lost when dumping symbols w/o DW_AT_ranges.
Gabriele - is this still an issue?
Comment 9•6 years ago
|
||
There are still some unsymbolicated crashes on Nightly:
I fixed one more bug related to this (bug 1510574) so this might be a separate issue, I'll try to investigate, leaving the NI? for now.
Comment 11•5 years ago
|
||
Unfortunately there's still crash reports with unsymbolicated stacks for recent builds, so they must be unrelated to the previous fixes we landed. I'll have to look at them individually.
Comment 12•2 years ago
|
||
We're no longer seeing this issue during fuzzing.
Comment 13•2 years ago
|
||
(In reply to Jason Kratzer [:jkratzer] from comment #12)
We're no longer seeing this issue during fuzzing.
Good, this part of the crash reporting machinery has been extensively overhauled and supports things we only dreamed we would support when this bug was filed so chances are it was fixed along the way.
Description
•