Closed
Bug 1303451
Opened 8 years ago
Closed 8 years ago
ImageBridgeParent::GetInstance fires an assert when GPU process dies
Categories
(Core :: Graphics, defect)
Core
Graphics
Tracking
()
RESOLVED
INVALID
People
(Reporter: gw280, Assigned: gw280)
References
(Blocks 1 open bug)
Details
(Whiteboard: [gfx-noted])
Got this when I killed the GPU proc:
[Parent 9944] ###!!! ASSERTION: ImageBridgeParent for the process: 'sImageBridges.count(aId) == 1', file /home/george/dev/gecko-dev/gfx/layers/ipc/ImageBridgeParent.cpp, line 366
It looks like there are a bunch of asserts related to ImageBridgeParent; e.g. http://searchfox.org/mozilla-central/source/gfx/layers/ipc/CompositorBridgeParent.cpp#137
I will investigate more.
Assignee | ||
Updated•8 years ago
|
Blocks: gpu-restart, 1297568
Assignee | ||
Comment 1•8 years ago
|
||
OK, what's going on here is that ImageBridgeParent lives in the GPU process, and all its instances (held in sImageBridges) live in the GPU process.
When the GPU process dies, it moves into the parent process, and our static GetInstance() fails because the instance it's trying to grab for whatever process lived in the GPU process.
I don't know enough about the code to say what the best solution is here, but I think we're going to need to hold off on using the ImageBridge somehow until we can spin a new GPU process and recreate all the singletons for each process.
Investigating further...
Updated•8 years ago
|
Whiteboard: [gfx-noted]
Blocks: e10s-gpu-win
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → gwright
Assignee | ||
Comment 2•8 years ago
|
||
So looking at this, I don't think we need to worry about this. I've gone through the code, and it looks like this is what happens:
GPU process dies; we end up in ContentParent::OnUnexpectedCompositorShutdown(). This starts by recreating the ImageBridgeParent via GPUProcessManager::CreateContentImageBridge(), and sending the ImageBridgeParent Endpoint over to the child, which then recreates its ImageBridgeChild in ContentChild::RecvReinitRendering() and ImageBridgeChild::ReinitForContent().
It looks like the assertion hits in between all this happening, and as it's an NS_ASSERTION rather than a MOZ_ASSERT, it's non-fatal, and just carries on as normal. I was worried that we weren't recreating the singletons at all, and wanted to dive in to confirm this and fix if necessary, but it looks like this is going to be one we can safely ignore.
The next question is, should we lave the NS_ASSERTION in there, given that it's non-fatal? I don't think we would derive value from bumping it up to something like gfxCriticalNote, as I don't feel like getting diagnostic data from our users that ImageBridgeParent has died is of any further value to us than just the local diagnostics we get from NS_ASSERTION.
Assignee | ||
Updated•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
Thanks, it sounds like we can drop the assertion or just ignore it then.
You need to log in
before you can comment on or make changes to this bug.
Description
•