Crash in mozalloc_abort | NS_DebugBreak | mozilla::ipc::FatalError | mozilla::dom::ContentChild::FatalErrorIfNotUsingGPUProcess | mozilla::layers::PCompositorBridgeChild::SendPLayerTransactionConstructor [clone .cold.536]

NEW
Assigned to

Status

()

P3
normal
a year ago
8 months ago

People

(Reporter: Ehsan, Assigned: dvander)

Tracking

({crash, regression})

unspecified
All
Linux
crash, regression
Points:
---

Firefox Tracking Flags

(firefox57- fix-optional, firefox58- wontfix, firefox59 ?)

Details

(Whiteboard: [gfx-noted], crash signature)

(Reporter)

Description

a year ago
I just got this crash: bp-5acce0f2-3cb8-4964-948b-3331c0170915

This happened when I opened a new tab to load planet.mozilla.org.  The tab stayed in the loading state and the content area remained white and I didn't understand why, and when I switched back to my Gmail tab (which was probably using the same process) I noticed it has crashed.

Looking at the signatures they all affect Linux, which makes sense given that we abort in FatalErrorIfNotUsingGPUProcess().
Crash Signature: mozalloc_abort | NS_DebugBreak | mozilla::ipc::FatalError | mozilla::dom::ContentChild::FatalErrorIfNotUsingGPUProcess | mozilla::layers::PCompositorBridgeChild::SendPLayerTransactionConstructor [clone .cold.536] → [@ mozalloc_abort | NS_DebugBreak | mozilla::ipc::FatalError | mozilla::dom::ContentChild::FatalErrorIfNotUsingGPUProcess | mozilla::layers::PCompositorBridgeChild::SendPLayerTransactionConstructor [clone .cold.536] ]
Crash Signature: [@ mozalloc_abort | NS_DebugBreak | mozilla::ipc::FatalError | mozilla::dom::ContentChild::FatalErrorIfNotUsingGPUProcess | mozilla::layers::PCompositorBridgeChild::SendPLayerTransactionConstructor [clone .cold.536] ] → [@ mozalloc_abort | NS_DebugBreak | mozilla::ipc::FatalError | mozilla::dom::ContentChild::FatalErrorIfNotUsingGPUProcess | mozilla::layers::PCompositorBridgeChild::SendPLayerTransactionConstructor [clone .cold.536] ] [@ mozalloc_abort | NS_DebugBreak | …
Crash Signature: [@ mozalloc_abort | NS_DebugBreak | mozilla::ipc::FatalError | mozilla::dom::ContentChild::FatalErrorIfNotUsingGPUProcess | mozilla::layers::PCompositorBridgeChild::SendPLayerTransactionConstructor [clone .cold.536] ] [@ mozalloc_abort | NS_DebugBreak | … → [@ mozalloc_abort | NS_DebugBreak | mozilla::ipc::FatalError | mozilla::dom::ContentChild::FatalErrorIfNotUsingGPUProcess | mozilla::layers::PCompositorBridgeChild::SendPLayerTransactionConstructor [clone .cold.536] ] [@ mozalloc_abort | NS_DebugBreak | …
Assignee: nobody → dvander
Priority: -- → P1
Whiteboard: [gfx-noted]

Updated

a year ago
OS: Unspecified → Linux
Hardware: Unspecified → All
This means that the IPDL connection between content and the compositor was broken. It's a fatal error in the not-GPU-process case, because it doesn't make sense that we'd suddenly lose a connection to the parent process. We expect that if the connection is lost, it's after we negotiate shutdown. Very recently we did change PCompositorManager to shutdown from the parent side if needed (bug 1389021), but that doesn't quite coincide with crash build dates. And it sounds like the crash here did not involve shutdown, it involved a tab switch.
FWIW, a friend of mine has got this several times over the last couple days.
Crash Signature: [@ mozalloc_abort | NS_DebugBreak | mozilla::ipc::FatalError | mozilla::dom::ContentChild::FatalErrorIfNotUsingGPUProcess | mozilla::layers::PCompositorBridgeChild::SendPLayerTransactionConstructor [clone .cold.536] ] [@ mozalloc_abort | NS_DebugBreak | … → [@ mozalloc_abort | NS_DebugBreak | mozilla::ipc::FatalError | mozilla::dom::ContentChild::FatalErrorIfNotUsingGPUProcess | mozilla::layers::PCompositorBridgeChild::SendPLayerTransactionConstructor [clone .cold.536] ] [@ mozalloc_abort | NS_DebugBreak | …
What are our plans with this bug? Are we at a point where we can't take this any further?

FWIW, low volume, probably not blocking. But currently an owned P1 in gfx and tracked for 57.
Flags: needinfo?(dvander)
Low volume, linux-only, so shouldn't block.
Flags: needinfo?(dvander)
Given that it's low volume, linux only and not being actively worked on, I doubt we will get to this in 57 :(, moving the tracking flag for 58 where it is more likely to be fixed. 

If the investigation resumes or crash volume goes up and there is a fix ready for uplift which is low risk, please nominate for beta57 uplift.
status-firefox57: affected → fix-optional
status-firefox58: --- → affected
tracking-firefox57: ? → -
tracking-firefox58: --- → ?

Comment 6

11 months ago
I just had 5 of these in a row on the latest Linux nightly (built from https://hg.mozilla.org/mozilla-central/rev/c6a2643362a67cdf7a87ac165454fce4b383debb). Eg: https://crash-stats.mozilla.com/report/index/bddca16c-a49b-4f1c-b921-540a00171016. After a restart, they stopped happening.
status-firefox58: affected → fix-optional
tracking-firefox58: ? → -
You need to log in before you can comment on or make changes to this bug.