1314711 - Killing the GPU process on Linux causes the parent process to terminate

Status: NEW

(Core :: Graphics, defect, P5)

Description

[George Wright (:gw280) (needinfo me!)]

This is *not* when you do a kill -9 $pid; this is when using the new KillProcess method introduced in bug 1314426. 

Not sure what's going on (yet), but we should probably keep track of it. It doesn't affect Windows.

Comment 1

[Darkspirit]

about:support > Terminate GPU process: Kills my KDE desktop session on Debian Stretch. I have to re-login then.

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

Patches welcome

Comment 4

[Andrew Osmond [:aosmond] (he/him)]

I'll look at this over the weekend.

Comment 5

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

This is part of what I ran into with bug 1564976. The first kill works normally:

(gdb) p/d $edi
$1 = 28911
(gdb) p/d $esi
$2 = 15
(gdb) bt
#0  0x00007fd1d2cdca90 in kill () at ../sysdeps/unix/syscall-template.S:78
#1  0x00007fd1cab362bb in base::KillProcess(int, int, bool) () at /usr/local/m-c/firefox/libxul.so
#2  0x00007fd1cb3f3bb1 in mozilla::gfx::GPUProcessManager::KillProcess() () at /usr/local/m-c/firefox/libxul.so
#3  0x00007fd1cb4f0406 in nsDOMWindowUtils::TerminateGPUProcess() () at /usr/local/m-c/firefox/libxul.so
#4  0x00007fd1ca66d382 in NS_InvokeByIndex () at /usr/local/m-c/firefox/libxul.so
#5  0x00007fd1caeab2c4 in XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) () at /usr/local/m-c/firefox/libxul.so

But then this happens:

(gdb) p/d $edi
$3 = 0
(gdb) p/d $esi
$4 = 15
(gdb) bt
#0  0x00007fd1d2cdca90 in kill () at ../sysdeps/unix/syscall-template.S:78
#1  0x00007fd1cab362bb in base::KillProcess(int, int, bool) () at /usr/local/m-c/firefox/libxul.so
#2  0x00007fd1cb3f132e in mozilla::gfx::GPUProcessHost::Shutdown() () at /usr/local/m-c/firefox/libxul.so
#3  0x00007fd1cb3f38eb in mozilla::gfx::GPUProcessManager::OnProcessUnexpectedShutdown(mozilla::gfx::GPUProcessHost*) () at /usr/local/m-c/firefox/libxul.so
#4  0x00007fd1cb3f3ae2 in mozilla::gfx::GPUProcessManager::NotifyRemoteActorDestroyed(unsigned long const&) () at /usr/local/m-c/firefox/libxul.so
#5  0x00007fd1cb34ab04 in mozilla::layers::CompositorBridgeChild::ActorDestroy(mozilla::ipc::IProtocol::ActorDestroyReason) () at /usr/local/m-c/firefox/libxul.so
#6  0x00007fd1cab7183e in mozilla::ipc::IProtocol::DestroySubtree(mozilla::ipc::IProtocol::ActorDestroyReason) () at /usr/local/m-c/firefox/libxul.so
#7  0x00007fd1cab717f0 in mozilla::ipc::IProtocol::DestroySubtree(mozilla::ipc::IProtocol::ActorDestroyReason) () at /usr/local/m-c/firefox/libxul.so
#8  0x00007fd1cabe5fe3 in mozilla::layers::PCompositorManagerChild::OnChannelError() () at /usr/local/m-c/firefox/libxul.so

One thing that I think should happen here is for base::KillProcess to reject non-positive pids on Unix and pseudo-handles on Windows, and I'm going to file a bug on that, but it would also be good for clients to check for this condition earlier, but the way we handle nullable pids needs some help to make that a reasonable thing to ask (e.g., the inconsistency between 0 vs. mozilla::ipc::kInvalidProcessHandle).