1613128 - Crash in [@ shutdownhang | PR_MD_WAIT_CV | _PR_WaitCondVar | PR_Wait | mozilla::layers::SynchronousTask::Wait]

Status: RESOLVED WORKSFORME

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

Description

[Pascal Chevrel (relman team) -> :pascalc]

This bug is for crash report bp-edd8a34d-b699-4f7f-9a1d-bdd0c0200203.

Top 10 frames of crashing thread:

0 ntdll.dll NtWaitForSingleObject 
1 kernelbase.dll WaitForSingleObjectEx 
2 nss3.dll PR_MD_WAIT_CV nsprpub/pr/src/md/windows/w95cv.c:252
3 nss3.dll _PR_WaitCondVar nsprpub/pr/src/threads/combined/prucv.c:177
4 nss3.dll PR_Wait nsprpub/pr/src/threads/prmon.c:305
5 xul.dll mozilla::layers::SynchronousTask::Wait gfx/layers/ipc/SynchronousTask.h:25
6 xul.dll mozilla::layers::ImageBridgeChild::WillShutdown gfx/layers/ipc/ImageBridgeChild.cpp:545
7 xul.dll static mozilla::layers::ImageBridgeChild::ShutdownSingleton gfx/layers/ipc/ImageBridgeChild.cpp:529
8 xul.dll static mozilla::layers::ImageBridgeChild::ShutDown gfx/layers/ipc/ImageBridgeChild.cpp:518
9 xul.dll static gfxPlatform::ShutdownLayersIPC gfx/thebes/gfxPlatform.cpp:1419

Medium crasher on beta and release, a few crashes on nightly.
This crash started spiking with our 72 release early January and is visible in low numbers in our December betas.

Comment 1

[Nicolas Silva [:nical]]

The main in thread waiting for ImageBridge's SendWillClose synchronous handshake to complete but for some reason the compositor thread is hung or spending too much time to respond. RecvSendWillClose on the compositor side doesn't do much: it simply iterates over the remaining texture hosts and calls DeallocateDeviceData which for the D3D11 backend just clears the mTexture pointer.

It could be that:

• the D3D11 texture's destructor is waiting on something that never completes upon deletion
• the compositor thread is already hung by something else and not picking up the WilClose message. Hard to tell what though, since we don't have stacks for the GPU/parent process.

there's a mix of intel and AMD in the reports (not specific to a particular vendor or device). All of the crashes I've looked at were using the D3D11 backend.

There are some " |[0][GFX1-]: Killing GPU process due to IPC reply timeout (t=986.773) " in the gfx critical log of maybe 1/5 crashes, most of the critical logs are empty so nothing terribly conclusive there.

Sotaro, are there any changes around gecko 72 you remember that could have led to shared muteces or other synchronization locking up ?

Comment 2

[Nicolas Silva [:nical]]

All of the crashes I've looked at were using the D3D11 backend.

Erratum: some webrender as well, though it's all windows so far, so I suspect that the common denominator is D3D11 video frame textures.

Comment 3

[sgarfinkle83]

I'm crashing multiple times a day. Is there any debug code I should enable? Alternately, is there a video driver setting I should change? FWIW, I'm using a GTX1060 GPU with a current or nearly-current nvidia driver.

Comment 4

[Sotaro Ikeda [:sotaro]]

(In reply to Nicolas Silva [:nical] from comment #1)

Sotaro, are there any changes around gecko 72 you remember that could have led to shared muteces or other synchronization locking up ?

Hmm, for gecko 72, gfx team was busy for WebRender. Then I noticed only few changes around D3D compositor. Bug 1608579 and Bug 1577336 are close to 72, but they seems not related to this bug.

Bug 1561179 is a change related to RDD process usage on 72. Though I am not sure yet, if it could be related to this problem.

Comment 6

[Andrew Osmond [:aosmond] (he/him)]

This graph is somewhat alarming as it seems to get worse every release.

Comment 7

[BugBot [:suhaib / :marco]]

Closing because no crashes reported for 12 weeks.