Child process reaper doesn't properly handle signaled children

RESOLVED INVALID

Status

()

Core
IPC
RESOLVED INVALID
8 years ago
8 years ago

People

(Reporter: cjones, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

There are two problems:

 (1) The reaper uses the chromium function |bool base::DidProcessCrash(bool* child_exited)| to determine whether a child has exited.  This function assumes (reasonably) that if a process was killed by "bad" signals, then it will exit "soon".  Because of OOP breakpad, that's not necessarily true, and the cases when it's not are those when breakpad IPC fails.  When/if those occur, we want to kill off the child.

 (2) I wrote an even dumber helper method WaitForChildExit() that will infinitely busy wait on waitpid(), but it doesn't account for signals at all.

Pretty easy to fix.
Oops, gave a second read over "man waitpid", and this is the only issue:

>  (2) I wrote an even dumber helper method WaitForChildExit() that will
> infinitely busy wait on waitpid(), but it doesn't account for signals at all.
(In reply to comment #0)
>  (2) I wrote an even dumber helper method WaitForChildExit() that will
> infinitely busy wait on waitpid(), but it doesn't account for signals at all.

Gah, according to the man page this code should have been fine too wrt breakpad.

I filed this bug because http://hg.mozilla.org/projects/electrolysis/rev/d87a958aab73 failed to pick up a minidump from the child that was terminated with SIGSEGV, while http://hg.mozilla.org/projects/electrolysis/rev/581822324d75 did so three times in a row.  Looking back over the diff, I'm not sure why that would be now.  I had thought that we were breaking out of the waitpid() in http://hg.mozilla.org/projects/electrolysis/rev/d87a958aab73 too early.  INVALID for now.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.