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

NEW
Unassigned

Status

()

Core
Graphics: Layers
P3
normal
2 years ago
a month ago

People

(Reporter: dbaron, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox45 affected)

Details

(Whiteboard: [gfx-noted])

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
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.
(Reporter)

Comment 1

2 years ago
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.
(Reporter)

Comment 2

2 years ago
Created attachment 8694529 [details]
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.
(Reporter)

Updated

2 years ago
Summary: Assertion failure: work_queue_.empty() on shutdown due to mozilla::layers::PTexture::Msg___delete____ID during shutdown after loading slack.com chat → 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
(Reporter)

Comment 3

2 years ago
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
(Reporter)

Comment 4

2 years ago
er, 4 above should say "is empty", not "is not empty"
Whiteboard: [gfx-noted]

Updated

2 years ago
See Also: → bug 1236350
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).
Depends on: 1236350
See Also: bug 1236350
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.