Crash in [@ mozilla::webgpu::WebGPUChild::TextureCreateView]
Categories
(Core :: Graphics: WebGPU, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
thunderbird_esr60 | --- | unaffected |
thunderbird_esr68 | --- | unaffected |
firefox-esr68 | --- | unaffected |
firefox76 | --- | disabled |
firefox77 | --- | disabled |
firefox78 | --- | disabled |
People
(Reporter: sg, Unassigned)
References
Details
(Keywords: crash)
Crash Data
This bug is for crash report bp-ccf3bac8-97a2-4b82-907f-5963e0200415.
Top 10 frames of crashing thread:
0 libxul.so mozilla::webgpu::WebGPUChild::TextureCreateView dom/webgpu/ipc/WebGPUChild.cpp:152
1 libxul.so mozilla::webgpu::Texture::CreateView dom/webgpu/Texture.cpp:37
2 libxul.so mozilla::dom::GPUTexture_Binding::createView dom/bindings/WebGPUBinding.cpp:20317
3 libxul.so bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions> dom/bindings/BindingUtils.cpp:3205
4 @0x3964065134cf
5 @0x7f23f02fd287
6 @0x3964068c2d5e
7 @0x7f2575564fff
8 @0x7f2575564fff
9 @0x7f2575564fff
There are several reports from Nightly on Windows and Linux. Most of the stack traces are cut off after the fourth frame. The crashes are all associated with http://joshgroves.com/gfx/wgpu/examples, where available. I can't reproduce the crash though (but the examples don't work either for me).
The first report is from build id 20200413034542. There's a similar one from build id 20200411093441, but the stack looks different there.
Comment 1•5 years ago
|
||
I just hit that, and I think I can explain. This happens when we lose the IPC connection to the GPU process. Creation of a texture view is the first thing that an application typically does in the frame, so this is where it fails. This falls under a more general "context loss handling" logic.
Updated•5 years ago
|
Comment 2•5 years ago
|
||
There is a popular sub-case where this was hit. The hello-triange example, which "wgpu.rs" redirects to, used an empty bind group layout. This was causing an access violation in some Vulkan drivers and crashing the GPU process. The crash would still register with this ^ signature, because the IPC got disconnected and the client failed to create a texture view. Yesterday, we fixed that example to not use the API incorrectly, so the crash volume will go down.
Comment 3•5 years ago
•
|
||
I am adding one more signature with a similar root cause. Feel free to remove it if it is not the same issue.
Updated•4 years ago
|
Comment 4•4 years ago
|
||
This is still basically a catch-all for all device lost bugs, until we handle them more gracefully on the GPU process side.
Updated•4 years ago
|
Comment 5•4 years ago
|
||
This should be good now with bug 1680376
Comment 6•3 years ago
|
||
Dzmitry, the crash doesn't seem to be fixed, do you mind take a look?
Updated•3 years ago
|
Comment 7•3 years ago
|
||
We are still occasionally hitting GPU process panics, should be much less often though.
Comment 9•2 years ago
|
||
Closing because no crashes reported for 12 weeks.
Description
•