1912550 - Crash in [@ mozilla::ipc::PortLink::SendMessage | IPC_Message_Name=PWebGPU::Msg_RenderPass]

Status: RESOLVED FIXED

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

Description

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

Crash report: https://crash-stats.mozilla.org/report/index/88a62616-2509-4001-a78e-0f38b0240809

MOZ_CRASH Reason: MOZ_CRASH(IPC message size is too large)

Top 10 frames of crashing thread:

0  xul.dll  mozilla::ipc::PortLink::SendMessage  ipc/glue/MessageLink.cpp:108
0  xul.dll  mozilla::ipc::MessageChannel::SendMessageToLink  ipc/glue/MessageChannel.cpp:811
0  xul.dll  mozilla::ipc::MessageChannel::Send  ipc/glue/MessageChannel.cpp:780
1  xul.dll  mozilla::ipc::IProtocol::ChannelSend  ipc/glue/ProtocolUtils.cpp:535
2  xul.dll  mozilla::webgpu::PWebGPUChild::SendRenderPass  ipc/ipdl/PWebGPUChild.cpp:286
3  xul.dll  mozilla::webgpu::CommandEncoder::EndRenderPass  dom/webgpu/CommandEncoder.cpp:260
4  xul.dll  mozilla::webgpu::RenderPassEncoder::End  dom/webgpu/RenderPassEncoder.cpp:340
4  xul.dll  mozilla::dom::GPURenderPassEncoder_Binding::end  dom/bindings/WebGPUBinding.cpp:24689
5  xul.dll  mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>  dom/bindings/BindingUtils.cpp:3268
6  ?  @0x00000163aa746508  

By querying Nightly crashes reported within the last 2 months, here are some insights about the signature:

• First crash report: 2024-06-12
• Process type: Content
• Is startup crash: No
• Has user comments: No
• Is null crash: Yes - 2 out of 4 crashes happened on null or near null memory address

Comment 1

[Glenn Watson [:gw]]

Starting as S2 but might actually be an S3, Jim?

Comment 2

[Erich Gubler [:ErichDonGubler] (he/him)]

There doesn't seem to be a security component here, and WebGPU is otherwise not shipped to the general public. Setting to S3.

Comment 3

[Jim Blandy :jimb]

Well, we shouldn't be trying to send IPDL messages that are so vast.

Comment 4

[Jim Blandy :jimb]

The current collection of crashes isn't inconsistent with one user playing around with very large render passes. The limit we're exhausting that causes this assertion is 256MiB in fuzzing builds, or 1.75GiB in other builds, so that's pretty generous.

If the volume jumps up, then we can re-triage, but this doesn't seem urgent to invest time in right now.

Comment 5

[Jim Blandy :jimb]

Marking this P5, as a performance problem.

Comment 6

[Andrew McCreight [:mccr8]]

(In reply to Jim Blandy :jimb from comment #4)

The current collection of crashes isn't inconsistent with one user playing around with very large render passes. The limit we're exhausting that causes this assertion is 256MiB in fuzzing builds, or 1.75GiB in other builds, so that's pretty generous.

It is an ifndef, so the limit is 256MB in normal builds. (We tried limiting it to 128MB which I think is more in line with Chrome but that caused too many problems.)

Comment 7

[Andrew McCreight [:mccr8]]

[@ mozilla::ipc::PortLink::SendMessage | IPC_Message_Name=PWebGPU::Msg_ComputePass ] are some similar crashes, which look like they are from the same machine. bp-5b087b18-bfb5-45d9-b58e-8c7ff0250123

Comment 8

[Jukka Jylänki]

A Unity games company Stratton Studios has been developing a really impressive looking Unity WebGPU game, that can be visited at https://play.projectprismatic.com/

Runs really great on Chrome, and attempted today to see how it would run on Firefox Nightly. That leads to this deterministic occurring crash at startup:

https://crash-stats.mozilla.org/report/index/b83b17cd-a75c-49bb-b814-e226c0250314#tab-details

STR:

1. Visit https://play.projectprismatic.com/
2. Wait for a while for the game to load. (that will take a minute or two) There is an intro video that plays while the game is loading.
3. Once the game has loaded, the tab will show the "Gah. Your tab just crashed." crash dialog.

E.g. another crash dump: https://crash-stats.mozilla.org/report/index/d6550fc1-4d57-4bba-8182-8e34b0250314

Comment 9

[Erich Gubler [:ErichDonGubler] (he/him)]

Jukka Jylänki: As much as possible, reports for specific sites should be tracked as individual bug entries; this enables us to analyze our most widespread blockers by count. Just filed bug 1954080 for you, which treats this bug as a blocker. 🙂

Comment 10

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

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 desktop browser crashes on nightly

:jimb, could you consider increasing the severity of this top-crash bug?

For more information, please visit BugBot documentation.

Comment 11

[Andy Leiserson [:aleiserson]]

It is possible that the fix for bug 1878804 will help with this.

Our current behavior (without this overload implemented) is to interpret the dynamicOffsetsData argument in its entirety as an iterable of dynamic offsets.

The use case for the 5-argument setBindGroup is wasm applications passing their entire heap. So it seems possible that an excessively large IPC message would result.

Comment 12

[Andy Leiserson [:aleiserson]]

Crash stats has no new crashes with this signature after build 20250327041043 (which was the last build without the fix for bug 1878804).

Comment 13

[Kelsey Gilbert [:jgilbert]]

Fixed by bug 1878804.