Closed Bug 1612523 Opened 6 years ago Closed 5 years ago

Crash in [@ nsWrapperCache::GetWrapper] under mozilla::dom::Navigator_Binding::get_gpu

Categories

(Core :: Graphics: WebGPU, defect, P3)

Unspecified
All
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr68 --- unaffected
firefox75 --- unaffected
firefox76 + fixed
firefox77 + fixed

People

(Reporter: emilio, Assigned: kvark)

References

Details

(Keywords: crash, regression)

Crash Data

This bug is for crash report bp-05ad85cf-38f2-4d76-9b03-852b90200131.

Top 10 frames of crashing thread:

0 libxul.so nsWrapperCache::GetWrapper const dom/base/nsWrapperCacheInlines.h:27
1 libxul.so mozilla::dom::Navigator_Binding::get_gpu dom/bindings/NavigatorBinding.cpp:2299
2 libxul.so bool mozilla::dom::binding_detail::GenericGetter<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions> dom/bindings/BindingUtils.cpp:3033
3 libxul.so js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:542
4 libxul.so js::CallGetter js/src/vm/Interpreter.cpp:746
5 libxul.so js::NativeGetProperty js/src/vm/NativeObject.cpp:2631
6 libxul.so js::GetProperty js/src/vm/Interpreter.cpp:4428
7 libxul.so Interpret js/src/vm/Interpreter.cpp:2700
8 libxul.so js::RunScript js/src/vm/Interpreter.cpp:422
9 libxul.so js::ExecuteKernel js/src/vm/Interpreter.cpp:798

I toggled the pref on, went to https://hello-webgpu-compute.glitch.me/, and clicked on the "Chromium/Firefox/Servo Demo".

(Note that this is only reproducible the first time, reloading the page worked)

Flags: needinfo?(dmalyshau)

Thank you for filing! Will look into it.

Assignee: nobody → dmalyshau
Status: NEW → ASSIGNED
Flags: needinfo?(dmalyshau)

It's fairly simple: even though the pref is switched to ON, the gfxConfig isn't updated automatically, and it thinks WebGPU is disabled. When the user tries to get a WebGPU instance, we are returning NULL. This isn't expected by the JS glue code.

Instead, we should probably allow the user to get the instance but not expose any adapters.

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(dmalyshau)
Points: --- → 3
Flags: needinfo?(dmalyshau)

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(dmalyshau)
Points: 3 → ---
Flags: needinfo?(dmalyshau)
Priority: -- → P3

[Tracking Requested - why for this release]:
these crash reports are spiking up in volume cross-platform after 76.0b5 got released to the beta audience - they are accounting for 2% of content crashes.
could this be related to the uplift in bug 1616741?

Flags: needinfo?(dmalyshau)
Keywords: regression
OS: Linux → All

No, bug 1616741 is the opposite, it tries to make sure that this never happens in Beta.
I think the spike is caused by more people trying out WebGPU examples in general. They still have to go and flip the pref before they crash. And when they get the version with bug 1616741, the pref will do nothing in Release/Beta, so we'll be in a better place.

Flags: needinfo?(dmalyshau)

We're still getting reports from 76.0b6 with the same-looking stack.
https://crash-stats.mozilla.org/report/index/7fefc164-ef3d-47e8-a7b1-519920200420

Also, the patch from bug 1616741 landed in time to ship with 76.0b5, so how would comment 7 explain the spike in that release?

Flags: needinfo?(dmalyshau)

You are right. I'm requesting the uplift to bug 1629955 fix, which should address this properly.

Flags: needinfo?(dmalyshau)

No crashes with 76.0b7 so far - looks like that fix worked.

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Depends on: 1629955
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.