9.71 KB, text/plain
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.
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.
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.
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
er, 4 above should say "is empty", not "is not empty"
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).