Panic Buffer has an uninitialized range with an end not aligned to 4 (end was 31) if buffer size is 31

[nical]

Description

Running into this assertion in the CTS after landing arcanization. There is a decent chance that this isn't actually caused by arcanization but is that it perhaps fixed something that led us to cover a case that was not run before.
Edit: I have growing confidence that it isn't related to arcanization and we might have had it before it landed.

Test log: https://treeherder.mozilla.org/logviewer?job_id=436806642&repo=try&lineNumber=2709

The assertion being hit is:

wgpu/wgpu-core/src/command/memory_init.rs

Line 244 in 16ec5b0

assert!(

The end of the range is 31.

At a glance, one might think that the logic that rounds up some range here would prevent that, but in practice the code that iterates the ranges here pulls from the original (not fixed up) ranges.

There is a lot going on here and my I haven't quite wrapped my head around it but a notable thing is that the buffer size is 31.

Repro steps

For firefox devs (or adventurous folks):

# in the mozilla-central repository
./mach wpt '/_mozilla/webgpu/chunked/63/cts.https.html?q=webgpu:shader,execution,robust_access_vertex:vertex_buffer_access:*'

I can upload a wgpu trace of the bug (although it's a bit large).

[ErichDonGubler]

Edited OP to separate the q query param. from URL path segments with a ?, instead of a space ( ). Seems like a typo?

[hdpotter]

I ran into this as well. As far as I can tell, sizes below 100 work fine, but sizes 101 and above fail if not divisible by four.

[Wumpf]

Likely related to

• Alignment guarantees for mapped buffers #3508