Crash in [@ mozilla::StyleGenericCalcNode<T>::~StyleGenericCalcNode]
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: gsvelto, Unassigned)
Details
(Keywords: crash, stalled)
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/10376530-1222-40cd-9f3d-5b3f30211230
Reason: EXCEPTION_ACCESS_VIOLATION_READ
Top 10 frames of crashing thread:
0 xul.dll mozilla::StyleGenericCalcNode<mozilla::StyleCalcLengthPercentageLeaf>::~StyleGenericCalcNode layout/style/ServoStyleConsts.h:1859
1 xul.dll nsStylePosition::~nsStylePosition layout/style/nsStyleStruct.cpp:1101
2 xul.dll servo_arc::Arc<style::gecko_bindings::structs::root::mozilla::GeckoPosition>::drop_slow<style::gecko_bindings::structs::root::mozilla::GeckoPosition> servo/components/servo_arc/lib.rs:363
3 xul.dll servo_arc::Arc<style::gecko_properties::ComputedValues>::drop_slow<style::gecko_properties::ComputedValues> servo/components/servo_arc/lib.rs:363
4 xul.dll style::gecko::arc_types::Servo_ComputedStyle_Release servo/components/style/gecko/arc_types.rs:128
5 xul.dll mozilla::RestyleManager::ProcessPostTraversal layout/base/RestyleManager.cpp:2898
6 xul.dll mozilla::RestyleManager::ProcessPostTraversal layout/base/RestyleManager.cpp:2847
7 xul.dll mozilla::RestyleManager::ProcessPostTraversal layout/base/RestyleManager.cpp:2847
8 xul.dll mozilla::RestyleManager::ProcessPostTraversal layout/base/RestyleManager.cpp:2847
9 xul.dll mozilla::RestyleManager::ProcessPostTraversal layout/base/RestyleManager.cpp:2847
This is a NULL pointer access. Most crashes are attempting to read from 0x0000000000000008 on 64-bit hosts and 0x00000004 on 32-bit ones. This crash seems to have been around for a while. Most of the crashes are happening on YouTube, Twitch plus a varied selection of NSFW pages so it might be related to video playback. There was nothing useful in the comments unfortunately.
|
||
Comment 1•4 years ago
|
||
I can try to poke. I don't see where the nullptr deref may be coming from...
|
|
||
Comment 2•4 years ago
|
||
So looking a bit more into it, they come from a variety of structs destructors (this is a very common type). Given that, I suspect some external memory corruption... :/
|
|
||
Updated•3 years ago
|
|
||
Comment 3•2 years ago
|
||
Now that crashstats has bitflip detection, I see that 21 of 48 crashes of this signature from the last week have non-zero bitflip confidence. So memory corruption seems like a good explanation for a at a big chunk of these.
|
||
Comment 4•1 year ago
|
||
had this crash several times, turned out to be unstable 13700kF due to degradation. lowering clocks to 5ghz fixed it.
|
|
||
Comment 5•1 year ago
|
||
Interesting, thanks!
|
||
Comment 6•1 year ago
|
||
The bug is linked to a topcrash signature, which matches the following criteria:
- Top 20 desktop browser crashes on beta
- Top 10 content process crashes on beta
:dholbert, could you consider increasing the severity of this top-crash bug?
For more information, please visit BugBot documentation.
|
||
Comment 8•1 year ago
|
||
(looking at recent crashes, I'm still seeing bitflips detected in a lot of them as mentioned in comment 3.)
|
|
||
Comment 9•1 year ago
•
|
||
I don't think this is actually a topcrash for beta, despite comment 6. The crash-data table here shows that we've received 2 total crashes for 138.0b1 from 1 install (and when comment 6 was posted, I think there was only 1 crash).
Notably comment 6 was posted very shortly after the new 138.0-beta cycle began, and I'm guessing we had very little crash data at all for 138 beta at that point (from just a handful of users running Firefox for a handful of hours). By definition, any crash during the first few hours of a new release cycle is briefly a "top crash" for that release, since the pool of overall crashes is quite small at that point.
But anyway, looking at the topcrash data for 138.0b1 today...
https://crash-stats.mozilla.org/topcrashers/?product=Firefox&version=138.0b1&days=14
...I don't see this bug listed at all. So we've gotten enough additional crash data from other real top-crashers to drown this one (and its 2 crashes from 1 install) out.
|
|
||
Comment 10•1 year ago
|
||
I filed https://github.com/mozilla/bugbot/issues/2623 to see if we can fix bugbot to avoid edits like comment 6 in the future.
|
|
||
Comment 11•1 year ago
|
||
The bug is linked to a topcrash signature, which matches the following criteria:
- Top 20 desktop browser crashes on beta
- Top 10 content process crashes on beta
For more information, please visit BugBot documentation.
|
|
||
Comment 12•1 year ago
|
||
Hmm, maybe this is being classified as a topcrash-on-beta based on all recent beta-channel crashes.
In the crash table on this bug page, for the "beta" row, that shows 21 crashes from 137.0 which I think are all really for release candidate builds. It seems conceivable that those 21 crashes represented enough crash volume to put this in the topcrash list for beta.
Those crashes seem to all come from 3 installations (~half from a single installation on Linux, and nearly all the rest from a 4-core windows installation, and 1 crash from another 12-core Windows installation).
The linux installation (in bp- 49757581-a21d-4af9-91fd-000a90250327) shows Possible bit flips max confidence 43% on all of them.
So: despite what looks like a spike here, this still seems to be due to bad hardware (with 2 users in particular having had a particularly bad day, who happened to be using 137 release candidate builds).
|
|
||
Comment 13•1 year ago
|
||
Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.
For more information, please visit BugBot documentation.
Description
•