It appears TextureChild::ActorDestroy is called as expected, but we don't set mIPCOpen to false. Instead we waited until TextureChild::ReleaseIPDLReference which too late for TextureChild::Destroy.
Assignee: nobody → aosmond
Status: NEW → ASSIGNED
Priority: -- → P3
STR, happens every time to me: 1) Build in debug mode for Linux. 2) Enable webrender and force separate GPU process. 3) Open any webpage to load a content process, and kill the GPU process. 4) Hits assertion.
Has STR: --- → yes
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
It'll be good to make sure this is not a problem without webrender.
Attachment #8872669 - Flags: review?(nical.bugzilla)
(In reply to Milan Sreckovic [:milan] from comment #2) > It'll be good to make sure this is not a problem without webrender. Good point. I confirmed it happens if I turn off gfx.webrender.enabled.
Component: Graphics: WebRender → Graphics
Just curious, do we plan on enabling the GPU process on linux?
(In reply to Mason Chang [:mchang] from comment #5) > Just curious, do we plan on enabling the GPU process on linux? I don't think so, but I think we should consider changing the pref default to auto-enable it if WebRender is in use. More robust and closer behaviour to Windows.
As of recently, the "GPU process" has nothing to do with the GPU (the official name was the "Compositor process" anyway :) We now allow the compositor process with software compositor. Which means that linux compositor process is not blocked on linux compositor acceleration, which increase the chances of it getting enabled sooner. No preset date for it though.
Attachment #8872669 - Flags: review?(nical.bugzilla) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/projects/graphics/rev/cf6ba2cbdea2 TextureChild::ActorDestroy should indicate IPC is now impossible, not TextureChild::ReleaseIPDLReference. r=nical
You need to log in before you can comment on or make changes to this bug.