Closed Bug 1630263 Opened 5 years ago Closed 2 years ago

Crash in [@ mozilla::webgpu::WebGPUChild::TextureCreateView]

Categories

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

defect

Tracking

()

RESOLVED WORKSFORME
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.

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.

Priority: -- → P3

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.

I am adding one more signature with a similar root cause. Feel free to remove it if it is not the same issue.

Crash Signature: [@ mozilla::webgpu::WebGPUChild::TextureCreateView] → [@ mozilla::webgpu::WebGPUChild::TextureCreateView][@ mozilla::webgpu::WebGPUChild::DeviceCreateCommandEncoder ]

This is still basically a catch-all for all device lost bugs, until we handle them more gracefully on the GPU process side.

Severity: -- → S3

This should be good now with bug 1680376

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED

Dzmitry, the crash doesn't seem to be fixed, do you mind take a look?

Flags: needinfo?(dmalyshau)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

We are still occasionally hitting GPU process panics, should be much less often though.

Depends on: 1709951
Flags: needinfo?(dmalyshau)

Closing because no crashes reported for 12 weeks.

Status: REOPENED → RESOLVED
Closed: 4 years ago2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.