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)

All
Windows 7
defect
Not set
critical

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)
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)
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.)
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
Matt, I know nothing about this code, do you have any ideas?
Flags: needinfo?(matt.woodrow)
Sorry, I've got no idea how enabling OMTC could affect style computation.
Flags: needinfo?(matt.woodrow)
I haven't tried to reproduce this in a while, but this was probably fixed with bug 930250.
Yeah, I haven't seen this crash once running with OMTC enabled for the past few days.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Depends on: 930250
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.