Closed Bug 1746062 Opened 3 years ago Closed 3 years ago

test case for bug 1742382 still crashes the browser

Categories

(Core :: Graphics: WebRender, defect)

Unspecified
Linux
defect

Tracking

()

RESOLVED FIXED
97 Branch
Tracking Status
firefox-esr91 --- wontfix
firefox95 --- wontfix
firefox96 --- wontfix
firefox97 --- fixed

People

(Reporter: freddy, Assigned: gw)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

Attachments

(2 files)

Attached file asan.log

When looking at the test case for bug 1742382 (during our bounty meeting), the linked 1MB test case still crashed Firefox Nightly on Linux.

Looks like a rust panic (causing MOZ_CRASH) due to unwrapping a None, but not in the software backend for webrender. Lee, is this bad?

Dan said it also crashed the browser for him on Mac OS, so he'll probably attach a log file as well.

Flags: needinfo?(lsalzman)
Crash Signature: [@ webrender::batch::BatchBuilder::add_segmented_prim_to_batch ]

The rust panic does not represent a security issue nor what occurred in bug 1742383.

Maybe Glenn should take a look to see what's going on.

Flags: needinfo?(lsalzman) → needinfo?(gwatson)

Test case is not public.

Blocks: wr-stability
Keywords: crash
OS: Unspecified → Linux
See Also: → 1663333, 1578183

In some extreme test cases, we have > 65535 clip masks being
created. Long term, we might want to restrict the page content
since we can't really render hundreds of thousands of clip masks
for performance reasons anyway. For now, just use a u32 for the
clip mask index so we can handle these cases a bit better.

Assignee: nobody → gwatson
Status: NEW → ASSIGNED
Flags: needinfo?(gwatson)
See Also: 1663333

Aren't we just kicking the can down the road into a memory/resource exhaustion problem at the OS level? It looks like this will still lead to some other crashy or instable situation. If nobody's stopping the test case from exceeding u16 why should u32 be an improvement? Can we find an operation in there where we can cancel/throw and do that instead?

It is kicking the can down the road (I alluded to this in the commit comment), you're right.

The benefit, I think, of landing this patch now is that we'll be able to see from crash-stats if this crash completely disappears, or if there is also some other bug that can cause us to incorrectly index into the clip instances array.

Pushed by gwatson@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/41bafe86e91c Support > 2^16 clip masks r=gfx-reviewers,lsalzman
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch

Hi Lee, I'm not sure if this is worth backporting to Beta/ESR or not. Seems like the patch would be low-risk and give parity with the branches receiving the original fix, but it also feels pretty edge case and unlikely to bite us in the wild. What are your thoughts?

Flags: needinfo?(lsalzman)
Flags: needinfo?(lsalzman) → needinfo?(gwatson)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: