在google_breakpad::ExceptionHandler::SignalHandler中父级崩溃或退出时，子挂起

Question

如果父进程在克隆子进程后崩溃，但在使用SendContinueSignalToChild()发送解除阻塞字节之前，则会发生这种情况。在这种情况下，管道文件句柄仍然是打开的，在read(...)上，子文件句柄在WaitForContinueSignal()中被无限阻塞。坠机后，通过init进程收养孩子。

复制的步骤：

l.在google_breakpad::ExceptionHandler::GenerateDump(CrashContext *context)中模拟父级崩溃

...
const pid_t child = sys_clone(
ThreadEntry, stack, CLONE_FILES | CLONE_FS | CLONE_UNTRACED, &thread_arg, NULL, NULL, NULL);

int r, status;
// Allow the child to ptrace us
sys_prctl(PR_SET_PTRACER, child, 0, 0, 0);


int *ptr = 0;  
*ptr = 42;     // <------- Crash here


SendContinueSignalToChild();
...

1. 向父(例如SIGSEGV)发送一个已处理的信号，以便对上述GenerateDump(...)方法进行增强。
2. 观察父级退出，但子级仍然存在，并在WaitForContinueSignal()上被阻塞。

上述步骤的输出

dmytro@db:~$ ./test &
[1] 25050
dmytro@db:~$ Test: started

dmytro@db:~$ ps aflxw | grep test
0  1000 25050 18923  20   0  40712  2680 -      R    pts/37     0:13          |   |           \_ ./test
0  1000 25054 18923  20   0   6136   856 pipe_w S+   pts/37     0:00          |   |           \_ grep --color=auto test
dmytro@db:~$ kill -11 25050

[1]+  Segmentation fault      (core dumped) ./test
dmytro@db:~$ ps aflxw | grep test
0  1000 25058 18923  20   0   6136   852 pipe_w S+   pts/37     0:00          |   |           \_ grep --color=auto test
1  1000 25055  1687  20   0  40732   356 pipe_w S    pts/37     0:00          \_ ./test

1687年是init pid。

在现实世界中，崩溃发生在一个与处理信号的线程平行的线程中。注意:这个问题也可能发生，因为正常的程序终止(即在并行线程中调用exit(0) )。

在Linux3.3.8-2.2、mips和i686平台上进行了测试。

所以，我的两个问题，

1. 这是预期的行为，断板库，以保持儿童的生存吗？我的期望是，孩子应该在父级崩溃/退出后立即退出。
2. 如果不是预期的行为，那么在父级崩溃/退出后完成客户端的最佳解决方案是什么？

提前感谢！

Answer 1

找到可能的解决办法了吗？

如果崩溃的线程不是main，并且父进程正是在这个时间段退出main()，那么在关闭崩溃期间也可能发生这种情况，因此显然这并不像乍一看那样不太可能发生。

此时，我认为这是因为CLONE_FILES标志的克隆()函数。这导致了这样的情况:如果父进程退出，子进程中的管道上的read()就不会返回EOF。

我还没有完成检查，如果我们能够安全地摆脱这个标志的克隆()调用。