Crash in [@ mozilla::ScrollFrameHelper::DecideScrollableLayer]

RESOLVED FIXED in Firefox 68

Status

()

defect
P2
critical
RESOLVED FIXED
2 months ago
Last month

People

(Reporter: calixte, Assigned: mattwoodrow)

Tracking

(Blocks 1 bug, Regression, {crash, regression})

Trunk
mozilla68
Unspecified
Windows 10
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox66 unaffected, firefox67 unaffected, firefox68+ fixed)

Details

(crash signature)

Attachments

(1 attachment)

Reporter

Description

2 months ago

This bug is for crash report bp-7f58db65-6ffe-471a-a862-e3eb00190502.

Top 10 frames of crashing thread:

0 xul.dll mozilla::ScrollFrameHelper::DecideScrollableLayer layout/generic/nsGfxScrollFrame.cpp:3934
1 xul.dll mozilla::ScrollFrameHelper::BuildDisplayList layout/generic/nsGfxScrollFrame.cpp:3307
2 xul.dll nsIFrame::BuildDisplayListForChild layout/generic/nsFrame.cpp:3903
3 xul.dll static void DisplayLine layout/generic/nsBlockFrame.cpp:6420
4 xul.dll nsBlockFrame::BuildDisplayList layout/generic/nsBlockFrame.cpp:6531
5 xul.dll nsIFrame::BuildDisplayListForChild layout/generic/nsFrame.cpp:3931
6 xul.dll static void DisplayLine layout/generic/nsBlockFrame.cpp:6420
7 xul.dll nsBlockFrame::BuildDisplayList layout/generic/nsBlockFrame.cpp:6531
8 xul.dll nsIFrame::BuildDisplayListForChild layout/generic/nsFrame.cpp:3931
9 xul.dll static void DisplayLine layout/generic/nsBlockFrame.cpp:6420

There are 3 crashes (from 3 installations) in nightly 68 with buildid 20190501215533. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1535945.

[1] https://hg.mozilla.org/mozilla-central/rev?node=0e259884f052

Flags: needinfo?(matt.woodrow)

This crash appears 41 times, in perhaps 15 ish different installations, in the
Windows nightlies 20190502220333 and 20190502095227.

Assignee

Updated

Last month
Assignee: nobody → matt.woodrow
Flags: needinfo?(matt.woodrow)
Assignee

Comment 2

Last month

It looks like we get a displayport added to a sub-scrollframe via MaybeCreateDisplayPortInFirstScrollFrameEncountered, but we don't paint that frame because it's offscreen.

Then on a latter paint, a descendant of the scrollframe becomes visible, making us do display list building for the scrollframe (it itself is still offscreen and unmodified, but its overflow area is visible).

On that paint, we detect that the displayport state has changed, but the frame isn't marked as invalid (it was on the paint where it first changed though), and we assert.

This should be fine, since the assert is trying to catch the case where we retain items even though we've changed. This case there are no items, and when it becomes visible we create new ones as needed.

The assert is getting overly complex though, so I'm just going to drop it.

Assignee

Updated

Last month
Priority: -- → P2

Comment 4

Last month
Pushed by mwoodrow@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ea3a73c7788e
Don't assert that we have an invalidated frame when we encouter a new displayport, since it can have changed on an earlier paint if we didn't have display items. r=tnikkel

Comment 5

Last month
bugherder
Status: NEW → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.