Closed Bug 1564015 Opened 5 years ago Closed 1 year ago

Crash in [@ nsLayoutUtils::GetNearestScrollableFrameForDirection]

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: gsvelto, Unassigned)

References

Details

(Keywords: crash)

Crash Data

This bug is for crash report bp-344bb079-d9ed-4fc7-b4e2-7745d0190707.

Top 10 frames of crashing thread:

0 XUL nsLayoutUtils::GetNearestScrollableFrameForDirection layout/generic/nsIFrame.h:609
1 XUL mozilla::PresShell::GetScrollableFrameToScrollForContent layout/base/PresShell.cpp:2817
2 XUL mozilla::layers::FocusTarget::FocusTarget gfx/layers/apz/src/FocusTarget.cpp:198
3 XUL mozilla::PresShell::Paint layout/base/PresShell.cpp:6023
4 XUL mozilla::dom::BrowserChild::MakeVisible dom/ipc/BrowserChild.cpp:2813
5 XUL mozilla::dom::BrowserChild::RecvRenderLayers dom/ipc/BrowserChild.cpp:2485
6 XUL InterruptCallback dom/ipc/ProcessHangMonitor.cpp:1216
7 XUL JSContext::handleInterrupt js/src/vm/Runtime.cpp:516
8 XUL <name omitted> js/src/jit/VMFunctions.cpp:320
9  @0xb0be5ec9bd1 

Even though I spotted it in nightly this doesn't look like a new crash as there's crash reports going back at least three versions. Crash stacks are consistent across versions and it looks like a NULL-pointer dereference.

Setting to P3 given low volume.

Appears APZ-related. Maybe when scrolling to a focused item. Botond, is this correct? Anything to go on here?

Flags: needinfo?(botond)
Priority: -- → P3

The crash is happening near the beginning of a paint, when we're gathering information about which element is focused to send to the compositor, to allow doing keyboard scrolling in the compositor. This codepath is newly added in bug 1351783.

I looked through the code we're using to gather this information, and I couldn't spot any problems like forgetting to null-check a pointer by inspection.

One thing that looks potentially suspicious, is that the call stack is showing frame construction code calling into JS, and that triggering the paint. Emilio, do you know if it's normal / expected for us to get into painting code while in the middle of frame construction (see example stack trace)?

Flags: needinfo?(botond) → needinfo?(emilio)

It is not. We have assertions to prevent that, and they do sometimes fire. I filed bug 1568051 to have a proper description of the issue, since we also had an intermittent bug with those assertions firing.

Flags: needinfo?(emilio)
QA Whiteboard: qa-not-actionable

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: critical → S3

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #5)

Closing because no crashes reported for 12 weeks.

Bad bot. This is incorrect, there are crashes as recently as few months ago.

(In reply to Timothy Nikkel (:tnikkel) from comment #6)

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #5)

Closing because no crashes reported for 12 weeks.

Bad bot. This is incorrect, there are crashes as recently as few months ago.

Last crash date is October 9, that's consistent with both "a few months ago" and "12 weeks".

(But maybe the bot should be waiting a longer period than 12 weeks before closing?)

Oh 12 weeks sorry. A bot closed a bug recently because of no crashes within a year, so my brain was thinking it was a year, probably because 12 weeks does seem a bit low.

You need to log in before you can comment on or make changes to this bug.