1229616 - Assertion failure: work_queue_.empty() on shutdown, from IPC destruction sequence of PTexture following destruction of FrameLayerBuilder::gMaskLayerImageCache during shutdown after loading slack.com chat

Status: NEW

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

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Steps to reproduce:
 1. make a new profile of firefox
 2. register an account for some slack.com chat (if needed) and log in
 3. close the browser
 4. start firefox with that profile
 5. load the relevant foo.slack.com site and wait for it to load
 6. close the browser

Actual results:  during shutdown I get:

Assertion failure: work_queue_.empty(), at /home/dbaron/builds/ssd/mozilla-central/mozilla/ipc/chromium/src/base/message_loop.cc:422

khuey and I debugged this far enough to determine that the IPC message was mozilla::layers::PTexture::Msg___delete____ID , but then rr started misbehaving.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I have an rr recording of this on a different machine that doesn't have the rr problem, though.

khuey says this is the result of not managing lifetimes correctly.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: stack for mozilla::layers::PTextureChild::SendDestroy

So this is the stack for mozilla::layers::PTextureChild::SendDestroy in the child process.  This sends a Destroy message to the parent process, which immediately replies with a __delete__ message.

But this stack is well into shutdown, so it doesn't seem surprising that after that __delete__ message is received, we don't process the message queue again.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

To be clear, I believe the sequencee of events is:

 1. the above stack happens in the child process during layout's module destructor (late in XPCOM shutdown)
 2. this sends a Destroy message to the parent process, which immediately replies with a __delete__ message
 3. the child receives the __delete__ message on the IPC thread and puts it in work_queue_
 4. the child asserts that work_queue_ is not empty

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

er, 4 above should say "is empty", not "is not empty"

Comment 5

[Nicolas Silva [:nical]]

This stack is way past the shutdown of gfx. Ideally the layout module would be shut down before gfx since it holds on to gfx resrouces (like textures). There's this code here https://dxr.mozilla.org/mozilla-central/rev/0771c5eab32f0cee4f7d12bc382298a81e0eabb2/gfx/layers/ipc/LayerTransactionChild.cpp#40 that's a sort of band aid for cases where textures outlive gfx shutdown, in which case we force the destruction of their ipdl actor and shared data during shutdown before the gfx ipdl machinery goes away. That's supposed to prevent this kind of crash from happening (it's a hack so the real solution is always to not hold on to gfx resources after gfx is shut down), so I am a bit surprised to see PTexture things alive that late after gfx is shut down. Maybe the shutdown code I pointed didn't run for whatever reason or some code tried to create new gfx resources after it ran (I would have expected things to blow up when creating the texture, though).