Crash in [@ nsLayoutUtils::GetNearestScrollableFrameForDirection]
Categories
(Core :: Layout, defect, P3)
Tracking
()
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.
Comment 1•5 years ago
|
||
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?
Comment 2•5 years ago
|
||
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)?
Comment 3•5 years ago
|
||
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.
Comment 4•2 years ago
|
||
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.
Comment 5•1 year ago
|
||
Closing because no crashes reported for 12 weeks.
Comment 6•1 year ago
|
||
(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.
Comment 7•1 year 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?)
Comment 8•1 year ago
|
||
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.
Description
•