setBindGroup without dynamic offsets crashes on Safari

[miloszmaki]

Safari WebGPU crashes: GPUComputePassEncoder.setBindGroup called with wrong dynamic offsets overload/type (Uint32Array required)

Environment

• App: C++/Wasm (Emscripten) + WebGPU

• Browser:

  • ✅ Chrome: works
  • ❌ Safari: fails at first compute pass bind

• Safari: WebGPU enabled via feature flag

• Repro: any compute dispatch that calls wgpu_encoder_set_bind_group(..., dynamicOffsets=nullptr, numDynamicOffsets=0) through this library’s JS glue

What happens

On Safari, the app fails with:

Unhandled Promise Rejection: TypeError:
Argument 3 ('dynamicOffsetsData') to GPUComputePassEncoder.setBindGroup
must be an instance of Uint32Array

Stack points into the generated WebGPU shim and the call to setBindGroup.

Root cause (suspected)

The library’s glue code always calls the “dynamic offsets” overload of WebGPU setBindGroup, even when no dynamic offsets are used.

Current glue implementation (excerpt):

wgpu_encoder_set_bind_group: function(encoder, index, bindGroup, dynamicOffsets, numDynamicOffsets) {
  // ...
  wgpu[encoder]['setBindGroup'](index, wgpu[bindGroup], HEAPU32, dynamicOffsets >> 2, numDynamicOffsets);
},

When numDynamicOffsets == 0 (the common case), Safari appears to treat argument 3 as dynamicOffsetsData and enforces that it’s a Uint32Array, rejecting the call path. Chrome accepts this.

Expected behavior

If numDynamicOffsets == 0, the glue should call the 2-argument overload:

encoder.setBindGroup(index, bindGroupOrNull);

If numDynamicOffsets > 0, the glue should pass a real Uint32Array (e.g. via subarray) to satisfy Safari’s type checks.

Proposed fix

Branch on numDynamicOffsets and use Safari-friendly typed array handling:

wgpu_encoder_set_bind_group: function(encoder, index, bindGroup, dynamicOffsets, numDynamicOffsets) {
  const bg = (bindGroup === 0) ? null : wgpu[bindGroup];

  if (numDynamicOffsets === 0) {
    wgpu[encoder]['setBindGroup'](index, bg);
    return;
  }

  const start = (dynamicOffsets >>> 2);
  const offsetsView = HEAPU32.subarray(start, start + numDynamicOffsets);
  wgpu[encoder]['setBindGroup'](index, bg, offsetsView);
},

[juj]

Thanks for the report. When you write "Safari crashes", what kind of crash is taking place? a JS exception? Or Safari browser is taken out altogether?

Happy to paper in a Safari-specific workaround, though would you be able to report an implementation bug directly against Apple Safari at https://bugs.webkit.org/ with your compiled Emscripten program as a test case? Maybe a future version will then be able to evolve the problem away.

Did applying the workaround navigate around the issue for you locally?

[miloszmaki]

The webgpu code is running on a dedicated worker, and the worker stops because of the error "TypeError: Argument 3 ('dynamicOffsetsData') to GPUComputePassEncoder.setBindGroup must be an instance of Uint32Array".

Yes, that's a good idea as well, I'll report to Safari too.

And yes, the fix mentioned above resolves the issue for me.

[juj]

Thanks for the clarification. To rule out one other possible alternative, I wonder if you might be using SharedArrayBuffer, and the argument 3 might be an instance to a shared Uint32Array? That is something that other browsers have gotten wrong in the past, and they misdistinguished between shared and unshared cases.

[miloszmaki]

I'm calling wgpu_compute_pass_encoder_set_bind_group(pass, 0, some_bind_group, nullptr, 0); where the bind group is created with wgpu_device_create_bind_group with a number of buffers created using wgpu_device_create_buffer.

[juj]

What I mean, is are you using -pthread, -sSHARED_MEMORY or -sWASM_WORKERS Emscripten linker settings?

If so, then the Emscripten build will target SharedArrayBuffer, and the arg 3 will be a shared Uint32Array, instead of an unshared Uint32Array.

The reason I am poking at this is that I find it a bit surprising to see that this line:

wgpu[encoder]['setBindGroup'](index, wgpu[bindGroup], HEAPU32, dynamicOffsets >> 2, numDynamicOffsets);

which unconditionally passes HEAPU32 to the call, would result in this specific error

Argument 3 ('dynamicOffsetsData') to GPUComputePassEncoder.setBindGroup must be an instance of Uint32Array

being printed: Argument 3 is always an instance of a Uint32Array - except in multithreaded builds, where it is a shared Uint32Array.

Hence pondering if that might be the case here?

The alternative of course is that Safari also bugged the error message.. but just wanted to rule out the case that SharedArrayBuffer was not being used here?

[juj]

After this commit there are workarounds for Firefox in these APIs that take in a heap object. That workaround will probably resolve also the Safari issue, so I'll close this issue as resolved.