Crash in IPCError-content | PContentChild::RecvReinitRendering

RESOLVED FIXED in Firefox 60

Status

()

Core
Graphics
--
critical
RESOLVED FIXED
27 days ago
8 days ago

People

(Reporter: calixte, Assigned: aosmond)

Tracking

({crash, regression})

Trunk
mozilla60
Unspecified
Windows 10
crash, regression
Points:
---

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox58 unaffected, firefox59 unaffected, firefox60 fixed)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

27 days ago
This bug was filed from the Socorro interface and is
report bp-d43cdd37-eecb-4f19-9129-8426f0180125.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll mozilla::dom::ContentChild::ProcessingError dom/ipc/ContentChild.cpp:2348
1 xul.dll mozilla::ipc::IPCResult::Fail ipc/glue/ProtocolUtils.cpp:64
2 xul.dll mozilla::dom::ContentChild::RecvReinitRendering dom/ipc/ContentChild.cpp:1372
3 xul.dll mozilla::dom::PContentChild::OnMessageReceived ipc/ipdl/PContentChild.cpp:5498
4 xul.dll mozilla::ipc::MessageChannel::DispatchAsyncMessage ipc/glue/MessageChannel.cpp:2110
5 xul.dll mozilla::ipc::MessageChannel::DispatchMessageW ipc/glue/MessageChannel.cpp:2040
6 xul.dll mozilla::ipc::MessageChannel::RunMessage ipc/glue/MessageChannel.cpp:1886
7 xul.dll mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1919
8 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1040
9 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:97

=============================================================

There are 16 crashes in nightly 60 starting with buildid 20180124220129.
The ipc_channel_error is PContentChild::RecvReinitRendering.
It could be a consequence of patch for bug 1432472.
:aosmond, could you investigate please ?
Flags: needinfo?(aosmond)
(Reporter)

Comment 1

27 days ago
My bad, there are 16 crashes for signature "IPCError-content | PContentChild::RecvInitRendering" and 3 for "IPCError-content | PContentChild::RecvReinitRendering".
Crash Signature: [@ IPCError-content | PContentChild::RecvReinitRendering] → [@ IPCError-content | PContentChild::RecvReinitRendering] [@ IPCError-content | PContentChild::RecvInitRendering]
(Assignee)

Comment 2

25 days ago
Bug 1432472 fixed CompositorManagerChild::CreateContentCompositorBridge so that in theory we would see more signatures from PContentChild::RecvReinitRendering but this is failing in CompositorManagerChild::Init, which is a few lines above. It is possible that the content process survives longer than it used with said patch, and now it falls over later on. However the volume on nightly was lower -- it would surprise me that it dies more frequently, if related (certainly the build dates line up and I don't see anything obvious in the pushlog.

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b0baaec09caf&tochange=32b850fa28ae
(Assignee)

Comment 3

16 days ago
The PContentChild::RecvReinitRendering crashes appear to be correlated with the crash in bug 1431448. If I filter out the WebRender enabled crashes, there are barely any left.
(Assignee)

Comment 4

10 days ago
The RecvInitRendering crashes appear to be happening because the GPU process was disabled before the content process was inititalized. If RecvInitRendering/RecvReinitRendering fail when trying to setup IPDL actors for the GPU process, we should fail silently, and wait for the next RecvReinitRendering to come in. If it fails with the UI process (after disabling the GPU process), then we can crash as we are. I think this will resolve the bulk of the crash reports (and I hope not cause a cascade of new related crashes due to the GPU process crashing so early in the init process...).
Assignee: nobody → aosmond
Status: NEW → ASSIGNED
Flags: needinfo?(aosmond)
(Assignee)

Comment 5

10 days ago
Created attachment 8950651 [details] [diff] [review]
0001-Bug-1433646-Allow-ContentChild-Recv-Re-InitRendering.patch, v1

This ignores failures in RecvInitRendering and RecvReinitRendering if the other side for the IPDL actor is the GPU process. The expectation is that it will receive another RecvReinitRendering as a result of the GPU process crashing. If it is the UI process, it should crash like it does today (and that's a good thing).

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7a95b8ce7ecf9e0e25ca074ce8d301e8539fa36b
(Assignee)

Updated

9 days ago
Attachment #8950651 - Flags: review?(rhunt)

Comment 6

9 days ago
Comment on attachment 8950651 [details] [diff] [review]
0001-Bug-1433646-Allow-ContentChild-Recv-Re-InitRendering.patch, v1

Review of attachment 8950651 [details] [diff] [review]:
-----------------------------------------------------------------

Nice catch!
Attachment #8950651 - Flags: review?(rhunt) → review+

Comment 7

9 days ago
Pushed by aosmond@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/82135389f392
Allow ContentChild::Recv(Re)InitRendering to fail with the GPU process. r=rhunt

Comment 8

8 days ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/82135389f392
Status: ASSIGNED → RESOLVED
Last Resolved: 8 days ago
status-firefox60: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
You need to log in before you can comment on or make changes to this bug.