George Wright (:gw280) (needinfo me!) Assignee
	Description • 8 years ago

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.

	George Wright (:gw280) (needinfo me!) 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...

	George Wright (:gw280) (needinfo me!) 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.

	David Anderson [:dvander] - inactive, e-mail if emergency
	Comment 3 • 8 years ago

Thanks, it sounds like we can drop the assertion or just ignore it then.