1734457 - Crash in [@ CreateWRCommandsForBorderSegment]

Status: RESOLVED WORKSFORME

(Core :: Graphics: WebRender, defect)

Description

[Chris Peterson [:cpeterson]]

64 crash reports from just one install of Beta 94.0b2. Maybe Fission related because this user has Fission enabled.

Tentatively marking as a potential security bug because the crash report says "Exploitability: high".

Crash report: https://crash-stats.mozilla.org/report/index/db194d6d-8ff7-4fff-9d3f-0d2cb0211006

Reason: EXCEPTION_ACCESS_VIOLATION_WRITE

Top 10 frames of crashing thread:

0 xul.dll CreateWRCommandsForBorderSegment layout/tables/nsTableFrame.cpp:6895
1 xul.dll nsTableFrame::IterateBCBorders layout/tables/nsTableFrame.cpp:7336
2 xul.dll mozilla::nsDisplayTableBorderCollapse::CreateWebRenderCommands layout/tables/nsTableFrame.cpp:7571
3 xul.dll mozilla::layers::WebRenderCommandBuilder::CreateWebRenderCommandsFromDisplayList gfx/layers/wr/WebRenderCommandBuilder.cpp:1811
4 xul.dll mozilla::nsDisplayOwnLayer::CreateWebRenderCommands layout/painting/nsDisplayList.cpp:5285
5 xul.dll mozilla::layers::WebRenderCommandBuilder::CreateWebRenderCommandsFromDisplayList gfx/layers/wr/WebRenderCommandBuilder.cpp:1811
6 xul.dll mozilla::layers::WebRenderLayerManager::EndTransactionWithoutLayer gfx/layers/wr/WebRenderLayerManager.cpp:362
7 xul.dll mozilla::nsDisplayList::PaintRoot layout/painting/nsDisplayList.cpp:2200
8 xul.dll static nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:3433
9 xul.dll mozilla::PresShell::PaintInternal layout/base/PresShell.cpp:6398

Comment 1

[Chris Peterson [:cpeterson]]

@ Matt: might this crash be a regression from your recent fix for "Don't use GetPaintRect for CreateWebRenderCommands" bug 1729236?

Comment 2

[Daniel Veditz [:dveditz]]

The stack is bouncing between WR and frame stuff, very odd.

The crash addresses for some of the stacks are weirdly related to esi register. For example, in bp-46495d0d-46f2-42dd-ac19-f29100211006 the crashing address is 0x20286d98 and esi is 0x00286d00. The 0x98 offset from the base address makes sense, but where does the initial 0x20000000 come from?

If it was just one crash I'd blame a random bitflip, but that's 64 crashes from this one person in a day. All 32 bit, maybe something up with that.

The crashing URLs were all on what looks like some internal company application -- not accessible.

Comment 3

[Matt Woodrow (:mattwoodrow)]

The crashing instruction is: movups xmmword ptr wrSide[ecx*4],xmm0, and the memory contents for that instruction is 0f 11 84 8e 98 00 00 00 (which I think is correct, but could be worth double checking).

wrSide is showing as 0x0057CAE8, and esp is 0x0057CA50, which gives us the 0x98 offset. ecx is 0.

Faulting address is writing to 0x2057CAE8

I also have no idea where the initial 0x20000000 comes from, but I really can't see see where the instruction would be reading it from.

If this is just one person, is it possible to be a CPU fault?

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Yeah, if it's just one install I don't think this is particularly actionable/worth spending lot of time into. The stack looks sane, fwiw.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Daniel Veditz [:dveditz] from comment #2)

The stack is bouncing between WR and frame stuff, very odd.

The "frame stuff" here is still all essentially WebRender/painting code which happens to live in layout -- stack levels 1-3 are the function nsDisplayTableBorderCollapse::CreateWebRenderCommands and its helpers. So I think it probably still makes sense to categorize this under WebRender at this point.

Comment 6

[Jim Mathies [:jimm]]

Miko, is this something you could look at?

Comment 7

[Miko Mynttinen]

We have had no new crashes reported with this signature since this bug was filed. Considering all the reports were from one install, I think we can close this for now and reopen if the signature reappears.