Open Bug 1614992 Opened 1 year ago Updated 9 months ago

Crash in [@ IPCError-browser | ShutDownKill | mozilla::layers::CompositorBridgeChild::FlushAsyncPaints]


(Core :: Graphics: Layers, defect, P3)




Tracking Status
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- fix-optional


(Reporter: sg, Unassigned)


(Keywords: crash)

Crash Data

This bug is for crash report bp-93e256f2-9e6c-4c53-8ca5-7d2f70200212.

Top 10 frames of crashing thread:

0 ntdll.dll NtWaitForAlertByThreadId 
1 ntdll.dll RtlSleepConditionVariableSRW 
2 kernelbase.dll SleepConditionVariableSRW 
3 mozglue.dll mozilla::detail::ConditionVariableImpl::wait mozglue/misc/ConditionVariable_windows.cpp:50
4 xul.dll mozilla::layers::CompositorBridgeChild::FlushAsyncPaints gfx/layers/ipc/CompositorBridgeChild.cpp:1132
5 xul.dll mozilla::layers::ClientLayerManager::FlushAsyncPaints gfx/layers/client/ClientLayerManager.cpp:486
6 xul.dll mozilla::layers::ClientLayerManager::EndTransactionInternal gfx/layers/client/ClientLayerManager.cpp:309
7 xul.dll mozilla::layers::ClientLayerManager::EndTransaction gfx/layers/client/ClientLayerManager.cpp:415
8 xul.dll nsDisplayList::PaintRoot layout/painting/nsDisplayList.cpp:3130
9 xul.dll static nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:4093

This seems to happen mostly on nightly, and presumably due to OMTP going AWOL somehow. The release/beta channel volumes are fairly low.

OS: Windows 10 → Windows
Priority: -- → P3
Hardware: x86_64 → Desktop

Added a few signatures. This happens only on nightly because we don't gather crash reports for content process shutdown kills on beta/release. I've looked into a few of the crashes and in most cases it seems the code is waiting here but there's no activity on any of the other threads in the process, as if it were deadlocked.

Crash Signature: [@ IPCError-browser | ShutDownKill | mozilla::layers::CompositorBridgeChild::FlushAsyncPaints] → [@ IPCError-browser | ShutDownKill | mozilla::layers::CompositorBridgeChild::FlushAsyncPaints] [@ IPCError-browser | ShutDownKill | xul.dll | mozilla::layers::CompositorBridgeChild::FlushAsyncPaints] [@ IPCError-browser | ShutDownKill | ntdll.dll | xul.…

I've re-analyzed some of these crashes and it seems that in all of them the content process was processing a refresh driver tick. None of the reports in the last week has the IPCShutdownState annotation set which means that they did not even acknowledge the IPC shutdown message. Most likely the refresh driver tick message was sitting in the queue before the shutdown one and so we never got to process it.

Added a macOS-specific signature

Crash Signature: xul.dll | kernelbase.dll | mozglue.dll | mozilla::layers::CompositorBridgeChild::FlushAsyncPaints] → xul.dll | kernelbase.dll | mozglue.dll | mozilla::layers::CompositorBridgeChild::FlushAsyncPaints] [@ IPCError-browser | ShutDownKill | __psynch_cvwait | <name omitted> | mozilla::layers::CompositorBridgeChild::FlushAsyncPaints]

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

The OMTP threads seem to be doing real work so this could just be the case of a really long paint.

You need to log in before you can comment on or make changes to this bug.