950052 - Crash in nsStyleSet::ReparentStyleContext after opening external link with OMTC Direct3D11 enabled

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Emanuel Hoogeveen [:ehoogeveen]]

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.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Brian Carpenter [:geeknik]]

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

[Bas Schouten (:bas.schouten)]

Matt, I know nothing about this code, do you have any ideas?

Comment 5

[Matt Woodrow (:mattwoodrow)]

Sorry, I've got no idea how enabling OMTC could affect style computation.

Comment 6

[Emanuel Hoogeveen [:ehoogeveen]]

I haven't tried to reproduce this in a while, but this was probably fixed with bug 930250.

Comment 7

[Emanuel Hoogeveen [:ehoogeveen]]

Yeah, I haven't seen this crash once running with OMTC enabled for the past few days.