Crash in mozilla::ipc::MessageChannel::WillDestroyCurrentMessageLoop

ASSIGNED
Assigned to

Status

()

Core
Graphics
--
critical
ASSIGNED
2 months ago
a month ago

People

(Reporter: marcia, Assigned: dvander)

Tracking

({crash, leave-open, topcrash})

55 Branch
x86
Windows 7
crash, leave-open, topcrash
Points:
---

Firefox Tracking Flags

(firefox55 affected)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

2 months ago
This bug was filed from the Socorro interface and is 
report bp-bce93404-ea89-4166-a0b5-53f842170413.
=============================================================

Seen while looking at nightly crash data - crashes started using 20170413030227 build: http://bit.ly/2pbBhxo

Possible regression window based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f40e24f40b4c4556944c762d4764eace261297f5&tochange=819a666afddc804b6099ee1b3cff3a0fdf35ec15

Bug 1349699? ni on billm
Flags: needinfo?(wmccloskey)
Any chance you could look at this David? It's an assertion where the compositor thread shuts down before the PCompositorBridgeParent protocol has closed (I had to click on the raw JSON file to find the ProtocolName field). I guess this user doesn't have a GPU process.
Component: IPC → Graphics
Flags: needinfo?(wmccloskey) → needinfo?(dvander)
(Reporter)

Comment 2

a month ago
This is now the top browser crash on Nightly.
Keywords: topcrash
Created attachment 8859373 [details] [diff] [review]
make DEBUG-only

For now let's make this DEBUG-only. There's no reason to crash everybody.
Assignee: nobody → wmccloskey
Attachment #8859373 - Flags: review?(continuation)
Keywords: leave-open
Attachment #8859373 - Flags: review?(continuation) → review+

Comment 4

a month ago
Pushed by wmccloskey@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/edda32a96d46
Make MessageChannel::WillDestroyCurrentMessageLoop assertion DEBUG-only (r=mccr8)

Comment 5

a month ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/edda32a96d46
(Assignee)

Updated

a month ago
Blocks: 1356448
(Assignee)

Comment 6

a month ago
Created attachment 8859919 [details] [diff] [review]
fix

Milan managed to accidentally reproduce this on try by enabling the GPU process in more places, and I think this is the likely cause. VideoBridgeParent and VsyncBridgeParent both run on the compositor thread, but don't retain a reference to CompositorThreadHolder. As long the holder is alive, the compositor thread will spin an event loop to wait for other threads to receive ActorDestroys.

The fix is to just hold a ref in both of these actors.
Assignee: wmccloskey → dvander
Status: NEW → ASSIGNED
Flags: needinfo?(dvander)
Attachment #8859919 - Flags: review?(matt.woodrow)
If this is the problem, why would the protocol be reported as PCompositorBridgeParent?
(Assignee)

Comment 8

a month ago
Probably we're seeing two different bugs, then. By xpcom-shutdown time, it's too late to report crash metadata in the GPU process, so I had to guess the protocol by looking at the stack.

This does appear to fix the issue Milan saw on try.
Attachment #8859919 - Flags: review?(matt.woodrow) → review+

Comment 9

a month ago
Pushed by danderson@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9fd7a385411f
Fix a race condition between VideoBridge and Compositor thread shutdown. (bug 1356365, r=mattwoodrow)

Comment 10

a month ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/9fd7a385411f
(Assignee)

Comment 11

a month ago
No crashes after 20170418030220 so far, which doesn't really line up to when this landed. But the crash rate dropped quite a bit after 4/21.
I disabled the assertion on the 18th, so we need to re-enable it to see what was fixed.
You need to log in before you can comment on or make changes to this bug.