Closed Bug 1595395 Opened 4 years ago Closed 4 years ago

Crash in [@ mozilla::ipc::ProcessLink::SendMessage | IPC_Message_Name=PWindowGlobal::Reply_DrawSnapshot]


(Core :: DOM: Content Processes, defect, P2)

70 Branch



Fission Milestone M5
Tracking Status
firefox-esr68 --- unaffected
firefox70 --- wontfix
firefox71 --- wontfix
firefox72 --- fixed


(Reporter: jseward, Assigned: mattwoodrow)



(Keywords: crash, regression)

Crash Data


(1 file)

This bug is for crash report bp-6e4f6657-468a-4abe-8636-2a2c50191108.

This crash appears in 3 different installations in the Windows nightly

Top 10 frames of crashing thread:

0 xul.dll void mozilla::ipc::ProcessLink::SendMessage ipc/glue/MessageLink.cpp:151
1 xul.dll mozilla::ipc::MessageChannel::Send ipc/glue/MessageChannel.cpp:1020
2 xul.dll mozilla::ipc::IProtocol::ChannelSend ipc/glue/ProtocolUtils.cpp:477
3 xul.dll void std::_Func_impl_no_alloc<`lambda at z:/task_1573163227/build/src/obj-firefox/ipc/ipdl/PWindowGlobalChild.cpp:518:45', void, mozilla::gfx::PaintFragment&&>::_Do_call 
4 xul.dll mozilla::dom::WindowGlobalChild::RecvDrawSnapshot dom/ipc/WindowGlobalChild.cpp:359
5 xul.dll mozilla::dom::PWindowGlobalChild::OnMessageReceived ipc/ipdl/PWindowGlobalChild.cpp:548
6 xul.dll mozilla::dom::PContentChild::OnMessageReceived ipc/ipdl/PContentChild.cpp:8096
7 xul.dll void mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2130
8 xul.dll mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:2003
9 xul.dll mozilla::SchedulerGroup::Runnable::Run xpcom/threads/SchedulerGroup.cpp:295

Flags: needinfo?(matt.woodrow)

It looks like we're failing to send the message because it's too large.

We're not using DrawSanpshot for anything outside of testing yet, so not a huge priority, but we probably need to put the recordings into shmem instead of serializing them into the IPC message.

Flags: needinfo?(matt.woodrow)
Keywords: regression
Version: unspecified → 72 Branch

Based on comment 1 I'm going to set it as fix-optional. Is that ok with you, Matt?

Flags: needinfo?(matt.woodrow)

Yes, fix-optional is totally the right thing for now.

Flags: needinfo?(matt.woodrow)

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(jmathies)

Matt, people are reporting this issue for Marionette and geckodriver (bug 1598731) while testing websites with Selenium. Given that we switched with Marionette to this new Fission compatible API (bug 1559592) it is basically a bad regression for us.

Blocks: 1559592
Flags: needinfo?(matt.woodrow)
OS: Windows 10 → All
Hardware: Unspecified → All
Version: 72 Branch → 70 Branch

This is more of a Fission issue, so I'm forwarding Jim's ni to Neha.

Flags: needinfo?(jmathies) → needinfo?(nkochar)
Fission Milestone: --- → M5
Flags: needinfo?(nkochar)
Priority: -- → P2
Assignee: nobody → matt.woodrow
Flags: needinfo?(matt.woodrow)

:mattwoodrow, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.

Flags: needinfo?(matt.woodrow)

We serialize an empty sized fragment if memory allocation fails rather than failing serialization to avoid crashing.
CrossProcessPaint::ReceiveFragment checks for an empty fragment, and reports an error to the caller, so this can be handled.

Pushed by
Use Shmem for gfx::PaintFragment so that we can handle serializing large images. r=rhunt
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72

Please note that I also just hit this crash with an older Nightly build when selecting the IRCCloud tab:

Flags: needinfo?(matt.woodrow)
You need to log in before you can comment on or make changes to this bug.