c - gdb 在调试程序行为中改变了什么 w.r.t. `accept()` 和 `close()`

Question

我一直在追寻一个问题:退出时应用程序挂起，但当您调试时一切正常。它归结为 15 年前某人做出的错误假设，具体来说，他假设如果一个线程正在等待 accept() - 在另一个线程中关闭该句柄将导致 accept() 失败。一些进程展开代码取决于这个假设(我知道这个假设是不正确的)。

问题:为什么这个假设在调试程序时成立？执行环境具体有哪些变化？

编辑在 CentOS 7 中观察

编辑 2: 我知道这是一个 UB，我需要修复它。我的问题不是“怎么办？”但是“为什么会这样？”。我很好奇，因为通过像这样的副作用来感知调试器的能力非常酷，有一天可能会派上用场。

编辑 3:

我发现如果您的进程安装了信号处理程序并且(在关闭 fd 之后)您将该信号(通过 pthread_kill())发送到当前在 accept() 中休眠的线程 -- 该调用总是立即返回(带有 EBADF 错误)。不管你的处理程序在做什么(只要它返回)。看起来信号传递导致线程唤醒，中断 accept() 并重新启动它(此时它检查相关文件“句柄”是否正确并错误退出)。

我不鼓励依赖这种行为，但对原始问题提出一个可能的解释——也许 gdb 会周期性地用一些信号唤醒每个线程？或者作为 ptraced 意味着内核(出于某种原因)将定期唤醒每个线程，“就好像”它被信号中断一样？

Answer 1

来自 ptrace man :

Signal injection and suppression

After signal-delivery-stop is observed by the tracer, the tracer should restart the tracee with the call

   ptrace(PTRACE_restart, pid, 0, sig)

where PTRACE_restart is one of the restarting ptrace requests. If is 0, then a signal is not delivered. Otherwise, the signal sig is delivered. This operation is called signal injection in this man‐ ual page, to distinguish it from signal-delivery-stop.

The sig value may be different from the WSTOPSIG(status) value: the tracer can cause a different signal to be injected.

Note that a suppressed signal still causes system calls to return prematurely. In this case, system calls will be restarted: the tracer will observe the tracee to reexecute the interrupted system call (or restart_syscall(2) system call for a few system calls which use a different mechanism for restarting) if the tracer uses PTRACE_SYSCALL. Even system calls (such as poll(2)) which are not restartable after signal are restarted after signal is suppressed; however, kernel bugs exist which cause some system calls to fail with EINTR even though no observable signal is injected to the tracee.

在我的例子中，终止逻辑从传递信号(被 gdb 拦截)开始，然后注入(inject)到被跟踪的进程中。 strace-ing gdb 产生:

ptrace(PTRACE_PEEKTEXT, 2274, 0x7f0c9d0ee2e0, [0x7f0ca013ab80]) = 0      <-- gdb woke up to SIGTERM directed at tracee
ptrace(PTRACE_PEEKUSER, 2274, 8*SS + 8, [0x7f0ca013a8c0]) = 0
ptrace(PTRACE_GETREGS, 2274, 0, 0x7ffdb4f2c3a0) = 0
...
ptrace(PTRACE_CONT, 2338, 0x1, SIG_0)   = 0
ptrace(PTRACE_CONT, 2274, 0x1, SIGTERM) = 0     <-- SIGTERM is delivered to a thread chosen by kernel
...
ptrace(PTRACE_CONT, 2276, 0x1, SIG_0)   = 0     <-- all other threads are restarted
...

请注意，这不足以完全解释行为，因为在 accept() 中休眠的线程可以在其他线程关闭文件描述符之前重新启动系统调用。

但是 strace 日志充满了相似的命令序列(PTRACE_PEEKTEXT 后面跟着数量不断减少的 PTRACE_CONT)。这里发生的是 gdb 在每个线程终止时唤醒，从 tracee 中提取一些数据并重新启动(剩余的)线程，导致系统调用重新启动。 IE。随着线程一个接一个地退出，每个剩余的线程都会停止并重新启动多次，最终导致 accept() 在文件描述符被另一个线程关闭后 重新启动。事实上，它肯定会发生，因为所述线程在关闭后退出。