1699201 - Moz crash in release - MOZ_CRASH(Illegal ID in DispatchCommand)

Status: RESOLVED FIXED

(Core :: Graphics: CanvasWebGL, defect)

Description

[Jim Mathies [:jimm]]

The graphics team has been looking at crash data int eh gpu process. We should have better visibility into top crashes here shortly using the crash ping telemetry. One issue that showed up in a list of top MOZ_CRASH reasons appears to be related to WebGL remoting -

MOZ_CRASH(Illegal ID in DispatchCommand)
https://searchfox.org/mozilla-central/rev/1a47a74bd5ba89f2474aa27c40bd478e853f3276/dom/canvas/WebGLCommandQueue.h#195

https://sql.telemetry.mozilla.org/queries/78731/source?p_channel=release&p_version=86

Looks like something Jeff might want to take a look at.

Comment 1

[Kelsey Gilbert [:jgilbert]]

We see there over 20k crashes, but we only see 400 crashes in crash-stats:
https://crash-stats.mozilla.org/signature/?product=Firefox&signature=mozilla%3A%3Adom%3A%3AWebGLParent%3A%3ARecvDispatchCommands&date=%3E%3D2021-02-17T18%3A45%3A00.000Z&date=%3C2021-03-17T18%3A45%3A00.000Z

Comment 2

[Kelsey Gilbert [:jgilbert]]

I'll be adding better diagnostic info here as part of this.
What I've found is that it's in TexImage with a 16000x8000 image upload that Deserialize fails. What happens is we make a call to CreateDataSourceSurfaceWithStride but AllowedSurfaceSize rejects our attempt, as the total byte size (512MB) is larger than our chosen max resource size (500MB).

I have a feeling we'll need to remove/reconfigure the max resource size. D3D (so D2D too) has a max resource size, but we only want to wrap a raw cpu data array. I though that's what CreateDataSourceSurfaceWithStride would do, but maybe I need a different entrypoint.

There's always CreateWrappingDataSourceSurface if we need to provide our own data, but that seems like a hack to me.

Comment 3

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1699201 - Pretty-print Deserialize failure func name and badArgId.

• Assert initial shmem alignments match expectation.

Comment 4

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1699201 - Wrap shmem for TexUnpackBlobDesc's DataSourceSurface deser.

• Add mochitest.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/759361b30156
Pretty-print Deserialize failure func name and badArgId. r=lsalzman
https://hg.mozilla.org/integration/autoland/rev/758d677f4da1
Wrap shmem for TexUnpackBlobDesc's DataSourceSurface deser. r=lsalzman

Comment 6

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/759361b30156
https://hg.mozilla.org/mozilla-central/rev/758d677f4da1

Comment 7

[Alexandru Ionescu (needinfo me) [:alexandrui]]

== Change summary for alert #29744 (as of Mon, 19 Apr 2021 20:46:54 GMT) ==

Improvements:

Ratio	Suite	Test	Platform	Options	Absolute values (old vs new)
6%	motionmark_webgl (docs)	3DGraphics-WebGL	macosx1015-64-shippable-qr	e10s stylo webgl-ipc webrender	14.00 -> 14.81
5%	motionmark_webgl (docs)	3DGraphics-WebGL	macosx1015-64-shippable	e10s stylo	14.04 -> 14.80
5%	motionmark_webgl (docs)	3DGraphics-WebGL	macosx1015-64-shippable-qr	e10s stylo webrender	14.02 -> 14.73

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=29744

Comment 8

[Kelsey Gilbert [:jgilbert]]

Plausible but surprising. I wouldn't think that texImage(Element) would show up so strongly there.