Faulty crash: Assertion failure: aPid == base::GetProcId(mChildProcessHandle) in GeckoChildProcessHost::OpenPrivilegedHandle

NEW
Unassigned

Status

()

Core
IPC
4 years ago
4 years ago

People

(Reporter: bjacob, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Created attachment 8369573 [details]
Faulty session

Found by Christoph Diehl's "Faulty" fuzzer, see bug 777067

This is another case of "bad child process triggers an assertion failure in parent process", similar to bug 963978. Similar to this bug, it might not be a real-world problem per se, but we at least need a way to have this kind of issue not prevent further fuzzing.
(Reporter)

Updated

4 years ago
Summary: Faulty crash: → Faulty crash: Assertion failure: aPid == base::GetProcId(mChildProcessHandle)
(Reporter)

Updated

4 years ago
Summary: Faulty crash: Assertion failure: aPid == base::GetProcId(mChildProcessHandle) → Faulty crash: Assertion failure: aPid == base::GetProcId(mChildProcessHandle) in GeckoChildProcessHost::OpenPrivilegedHandle
(Reporter)

Comment 1

4 years ago
Actually, this looks like a more clear-cut bug:

Code at ipc/glue/GeckoChildProcessHost.cpp:821:

817     void
818     GeckoChildProcessHost::OpenPrivilegedHandle(base::ProcessId aPid)
819     {
820       if (mChildProcessHandle) {
821         MOZ_ASSERT(aPid == base::GetProcId(mChildProcessHandle));
822         return;
823       }
824       if (!base::OpenPrivilegedProcessHandle(aPid, &mChildProcessHandle)) {
825         NS_RUNTIMEABORT("can't open handle to child process");
826       }
827     }


If I understand correctly, this OpenPrivilegedHandle function is "infallible" in that it hard-asserts, even in non-DEBUG builds, that base::OpenPrivilegedProcessHandle succeeds. But, on platforms where this function is non-trivial (like, Windows), this will fail if the child process just crashed, right? So this seems like something that should be handled gracefully, rather than "infallible". Is that correct?
Flags: needinfo?(bent.mozilla)
Yeah, parent failures should be graceful whenever it's reasonable to expect failure in the wild (at least imho). It may involve restructuring this code a bit though...
Flags: needinfo?(bent.mozilla)
(Reporter)

Comment 3

4 years ago
Non-gfx, unblocking gfx tracking bug.
No longer blocks: 963790
(Reporter)

Comment 4

4 years ago
Actually, no, I won't be able to get successful runs with Faulty until that is fixed.

Classification: non-gfx, hard (because of comment 2 "It may involve restructuring this code a bit though").
Blocks: 963790
You need to log in before you can comment on or make changes to this bug.