1655000 - Crash in [@ mozilla::gfx::Swizzle_SSE2<T>] with WebGL

Status: RESOLVED FIXED

(Core :: Canvas: WebGL, defect, P1)

Description

[Cristian Fogel, QA [:cfogel]]

Steps to reproduce

1. set: webgl.out-of-process to true
2. access: https://cesium.com/ion/stories/viewer/?id=2f0131ab-3948-4467-947c-411d5705a116

Notes:

• crash encountered on device with GPU - ATI Radeon 3000, but on others the page/test was loaded

This bug is for crash report bp-20483e28-7aef-4930-a626-23f660200724.

Top 10 frames of crashing thread:

0 xul.dll mozilla::gfx::Swizzle_SSE2<1, 0> gfx/2d/SwizzleSSE2.cpp:377
1 xul.dll mozilla::gfx::SwizzleData gfx/2d/Swizzle.cpp
2 xul.dll static gfxUtils::ConvertBGRAtoRGBA gfx/thebes/gfxUtils.cpp:261
3 xul.dll mozilla::WebGLContext::FrontBufferSnapshotInto dom/canvas/WebGLContext.cpp:1079
4 xul.dll mozilla::dom::WebGLParent::RecvGetFrontBufferSnapshot dom/canvas/WebGLParent.cpp:98
5 xul.dll mozilla::dom::PWebGLParent::OnMessageReceived ipc/ipdl/PWebGLParent.cpp:365
6 xul.dll mozilla::layers::PCompositorManagerParent::OnMessageReceived ipc/ipdl/PCompositorManagerParent.cpp:498
7 xul.dll mozilla::ipc::MessageChannel::DispatchSyncMessage ipc/glue/MessageChannel.cpp:2119
8 xul.dll mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2070
9 xul.dll mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1953

Comment 1

[Andrew Overholt [:overholt]]

I don't think we intend to ship WebGL remoting in 80, do we, Jeff?

Comment 2

[Jeff Gilbert [:jgilbert]]

(In reply to Andrew Overholt [:overholt] from comment #1)

I don't think we intend to ship WebGL remoting in 80, do we, Jeff?

Nope, only looking forward on this.

Comment 3

[Jeff Gilbert [:jgilbert]]

I think this was fixed by bug 1659874.
We'll watch crash reports to see if it's fixed on 81beta.

Comment 4

[Jeff Gilbert [:jgilbert]]

We've gotten a couple crashes still, even on Betas with bug 1659874 fixed.

Comment 5

[Cristian Fogel, QA [:cfogel]]

Encountered the same crash with 83.0a1(2020-10-08) on Win10:
https://www.shadertoy.com/view/3slcWr

Comment 6

[Release mgmt bot [:sylvestre / :calixte / :marco for bugbug]]

Change the status for beta to have the same as nightly and release.
For more information, please visit auto_nag documentation.

Comment 7

[Matt Woodrow (:mattwoodrow)]

I took a look into this report: https://crash-stats.mozilla.org/report/index/c20ebfcf-9e69-4422-af0c-4e5cb0210411

WebGLParent::RecvGetFrontBufferSnapshot is computing a 0x0 size from mHost->GetFrontBufferSize();, which still allocates a shmem successfully.

WebGLContext::FrontBufferSnapshotInto computes a non-empty size from mSwapChain.FrontBuffer()->mDesc.size (401568x1).

I think this would have hit the assert MOZ_ASSERT(dest.length() == stride * size.height) in a debug build.

Looks like this is the #4 topcrash in the GPU process.

Comment 8

[Jeff Gilbert [:jgilbert]]

Attachment: Bug 1655000 - Use same function for getting size as reading into buffer.

Previously we called GetFrontBufferSize, alloc'd a buffer, and called
FrontBufferSnapshotInto to read into the buffer.
Now, call FrontBufferSnapshotInto({}) to get size, and then alloc and
pass pointer to newly alloc'd data into
FrontBufferSnapshotInto(Some(ptr)).
Using the same function for both means that logic can't diverge and
cause mismatch bugs.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1331f134a250
Use same function for getting size as reading into buffer. r=lsalzman

Comment 10

[Alexandru Michis [:malexandru]]

Backed out changeset 1331f134a250 (Bug 1655000) for causing bustages in WebGLContext.cpp
Backout link: https://hg.mozilla.org/integration/autoland/rev/089f9acba4eef04aaa9920365e8398fe0984328b
Push with failures, failure log.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/497a9e22d0ce
Use same function for getting size as reading into buffer. r=lsalzman

Comment 12

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/497a9e22d0ce

Comment 13

[Release mgmt bot [:sylvestre / :calixte / :marco for bugbug]]

The patch landed in nightly and beta is affected.
:jgilbert, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 14

[Pascal Chevrel:pascalc]

The volume is not insignificant on the release channel, let's see if we can uplift it, Jeff could you request the uplift please? thanks

Comment 15

[Jeff Gilbert [:jgilbert]]

Comment on attachment 9218829 [details]
Bug 1655000 - Use same function for getting size as reading into buffer.

Beta/Release Uplift Approval Request

• User impact if declined: Crashes, not-insignificant volume
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Changes constrained to just a couple functions
• String changes made/needed: none

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9218829 [details]
Bug 1655000 - Use same function for getting size as reading into buffer.

Approved for 89.0b14.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/55e81873d600

Comment 18

[Bodea Daniel [:danibodea]]

I have managed to reproduce this issue on Release v88.0.1 and Beta v88.0b4; The behavior is: The page is loaded, then if the user attempts to zoom or interact with the website, the whole screen would turn black for 1 or 2 seconds, the website would show an error or it would crash completely.
A crash with the same crash signature would be recorded.

While attempting to verify the fix, I have attempted reproduction on Beta v89.0b14 and Nightly v90.0a1. The behavior is as follows: The page is loaded, then if the user attempts to zoom or interact with the website, the whole screen would turn black for 1 or 2 seconds and the page would show an error, but it does never really crash completely or record a crash report.

Based on the above, I can verify this fix, as it does not technically crash anymore, but the website is still unusable In any Firefox build.
Jeff, Should I log another bug for the remaining incorrect behavior?

The website displays the same error for both the affected and unaffected builds:
"Whoops
There was an unexpected error and this story cannot be loaded."