1674280 - Crash in [@ nsWrapperCache::GetWrapper] called from mozilla::dom::GPUDevice_Binding::createShaderModule

Status: RESOLVED WORKSFORME

(Core :: Graphics: WebGPU, defect)

Description

[Andrew McCreight [:mccr8]]

Crash report: https://crash-stats.mozilla.org/report/index/cb9138f6-aa2f-442b-ad60-9393e0201029

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0 xul.dll nsWrapperCache::GetWrapper const dom/base/nsWrapperCacheInlines.h:27
1 xul.dll mozilla::dom::GPUDevice_Binding::createShaderModule dom/bindings/WebGPUBinding.cpp:14765
2 xul.dll mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions> dom/bindings/BindingUtils.cpp:3229
3 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:598
4 xul.dll js::fun_call js/src/vm/JSFunction.cpp:1140
5 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:598
6 xul.dll Interpret js/src/vm/Interpreter.cpp:3336
7 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:635
8 xul.dll js::fun_call js/src/vm/JSFunction.cpp:1140
9 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:598

Some kind of null deref.

Comment 1

[Andrew McCreight [:mccr8]]

It looks like Device::CreateShaderModule can return null, and maybe the bindings code doesn't expect that?

  auto result(StrongOrRawPtr<mozilla::webgpu::ShaderModule>(MOZ_KnownLive(self)->CreateShaderModule(Constify(arg0))));
  MOZ_ASSERT(!JS_IsExceptionPending(cx));
  if (!GetOrCreateDOMReflector(cx, result, args.rval())) {

I'm not sure if I figured out what GetOrCreateDOMReflector actually does with a null value, but DoGetOrCreateDOMReflector does not deal with it.

Comment 2

[Andrew McCreight [:mccr8]]

If that's right, it looks like a regression from bug 1622846 .

Comment 3

[Emilio Cobos Álvarez (:emilio)]

If createShaderModule can return null then this line needs to be changed to GPUShaderModule? createShaderModule(GPUShaderModuleDescriptor descriptor); instead. That'd introduce the right null-check.

Comment 4

[Dzmitry Malyshau [:kvark]]

The API can't return NULL there, so IDL changes aren't needed. Our WIP implementation doesn't have all the validation code in place to throw the appropriate errors. It returns NULL likely because the user provided a WGSL module that we aren't handling at all yet. The whole error model of WebGPU is still being implemented.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:kvark, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[Dzmitry Malyshau [:kvark]]

Marking as S3 for WebGPU not being enabled by default, and only available in Nightly.

Comment 7

[Bob Clary [:bc] (inactive)]

I see this on Linux as well: bp-608a6128-6967-4b98-bc7c-e260e0201225

Comment 9

[Dzmitry Malyshau [:kvark]]

This is being fixed by https://phabricator.services.mozilla.com/D107013

Comment 10

[Dzmitry Malyshau [:kvark]]

Andrew, the original issue was fixed, but the crash signature is so generic that it gets a ton of unrelated hits (I can see nothing relevant to WebGPU in, say, https://crash-stats.mozilla.org/report/index/c064f64e-762c-4129-a8ba-1fcda0210527 that was reported today).
I'm worried that these are not getting properly prioritized (by the affected teams) because they are sitting in this bin.
Is there a good way for us to split the crash signatures out and close this bug?

Comment 11

[Andrew McCreight [:mccr8]]

Thanks for fixing the original issue.

The fix here would be to add nsWrapperCache::GetWrapper to the Socorro prefix list and file new bugs for the new signatures as needed, but the volume is low enough here, and the crashes seem a bit all over the place, so I'm not sure it is worth doing. Let's just close the bug.