Closed
Bug 950052
Opened 11 years ago
Closed 11 years ago
Crash in nsStyleSet::ReparentStyleContext after opening external link with OMTC Direct3D11 enabled
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
RESOLVED
FIXED
mozilla30
People
(Reporter: ehoogeveen, Unassigned)
References
Details
(Keywords: crash)
Crash Data
This bug was filed from the Socorro interface and is
report bp-0863383c-1ea5-44ca-9020-57e242131213.
=============================================================
I'm seeing this crash mostly on my laptop, but I've also had it once on my desktop. I confirmed that it happens on a clean profile, but it's intermittent.
STR:
1) From a fresh profile, set layers.offmainthreadcomposition.enabled to true.
2) Have the browser open, making sure it is set as the default browser without -no-remote so external links will be opened in the current window.
3) Click various links in InstantBird (other sources may work too) until you get a crash.
I think this happens because parentContext passed at
https://hg.mozilla.org/mozilla-central/annotate/1401e4b394ad/layout/base/RestyleManager.cpp#l2357
is null, which then gets dereferenced here:
https://hg.mozilla.org/mozilla-central/annotate/1401e4b394ad/layout/style/nsStyleSet.cpp#l1844
I don't know whether parentContext is expected to ever be null here, or if OMTC is breaking an invariant here, so filing it in Graphics: Layers for now, but ni? on dbaron who introduced this code in bug 898329.
Flags: needinfo?(dbaron)
Comment 1•11 years ago
|
||
0x4c would indeed be the mBits of a null nsStyleContext*, which would suggest one of aStyleContext or aNewParentContext is null. We'd have crashed sooner if aStyleContext were null, though.
This sort of thing smells like memory corruption, really. I'm hesitant to even investigate further.
Flags: needinfo?(dbaron)
Comment 2•11 years ago
|
||
I could imagine crashing this way is if some code is triggering a restyle on the root frame (which is an ancestor of the root element's frame, and which should never be done). But the stack goes through RestyleElement, which shouldn't lead to that, since I don't think the root frame isn't the primary frame for any element. (Or if we crashed whenever restyling the root frame, we'd have noticed a lot faster.)
Comment 3•11 years ago
|
||
I'm seeing this crash at least once a day when opening links from x-chat or pidgin w/ Nightly Holly builds on x64 Windows 8 Pro. It doesn't happen every time though, so catching it in WinDBG is going to be hard and running Holly inside WinDBG for daily browsing is painfully slow.
https://crash-stats.mozilla.com/report/index/524b2425-76c7-439a-aee6-c144a2140101
https://crash-stats.mozilla.com/report/index/91ea5bba-6c05-4e75-8284-b30672140102
Comment 4•11 years ago
|
||
Matt, I know nothing about this code, do you have any ideas?
Flags: needinfo?(matt.woodrow)
Comment 5•11 years ago
|
||
Sorry, I've got no idea how enabling OMTC could affect style computation.
Flags: needinfo?(matt.woodrow)
Reporter | ||
Comment 6•11 years ago
|
||
I haven't tried to reproduce this in a while, but this was probably fixed with bug 930250.
Reporter | ||
Comment 7•11 years ago
|
||
Yeah, I haven't seen this crash once running with OMTC enabled for the past few days.
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•