假设架构是 x86。操作系统是基于 Linux 的。给定一个单线程执行int 3指令的多线程进程，中断处理程序是停止执行整个进程还是只停止执行int 3指令的线程？
【问题讨论】：
ptrace 有点改变。虽然可以观察默认行为，但在 GDB 中，可以选择在到达断点时停止所有线程，或者在其余线程继续在后台运行时停止单个线程。从这个意义上说，在 GDB 中无法得到明确的答案。
标签： c++ c linux multithreading interrupt-handling
答案确实不是。 Int 3 用于触发断点。中断处理程序很小，中断及其处理程序都不会停止任何线程。
如果没有加载调试器，处理程序要么忽略它，要么调用操作系统采取某种错误操作，比如发出信号（可能是 SIGTRAP）。没有线程受到损害。
如果有一个进程内调试器，断点 ISR 会将控制权转移给它。断点不会停止任何线程，除了中断的线程。调试器可能会尝试挂起其他人。
如果存在进程外调试器，处理程序将调用它，但这必须通过操作系统进行调解才能进行合适的上下文切换。作为该切换的一部分，操作系统将暂停调试对象，这意味着它的所有线程都将停止。
【讨论】：
由于问题是特定于 Linux 的，让我们深入了解内核源代码！我们知道int 3 将生成一个SIGTRAP，正如我们在do_int3 中看到的那样。 default behaviour of SIGTRAP 是终止进程并转储内核。
do_int3 调用 do_trap，经过大量间接调用后，调用 complete_signal，大部分魔法都发生在这里。在 cmets 之后，无需太多解释就可以清楚地看到正在发生的事情：
编辑：回答评论：
当进程是ptraced 时，该行为在manual page 中有很好的记录（请参阅“信号传递停止”）。基本上，内核选择一个任意线程处理信号后，如果选择的线程被跟踪，它进入signal-delivery-stop——这意味着信号还没有传递给进程，并且可以被跟踪进程抑制.调试器就是这种情况：在调试时，死进程对我们没有用（这并不完全正确，但让我们考虑实时调试场景，这是唯一在这种情况下有意义的场景），所以默认情况下除非用户另有说明，否则我们会阻止 SIGTRAP。在这种情况下，被跟踪进程如何处理 SIGTRAP（SIG_IGN 或 SIG_DFL 或自定义处理程序）无关紧要，因为它永远不会知道它发生了。
请注意，在 SIGTRAP 的情况下，跟踪器进程必须考虑除正在停止的进程之外的各种情况，如手册页中每个 ptrace 操作下的详细说明。
【讨论】：
int 3 是不允许运行用户空间代码的特权指令。
内核随后会向您的进程发送一个 SIGTRAP 信号，而 SIGTRAP 信号的默认操作是终止整个进程。
很容易测试：
#include <thread>
#include <vector>
void f(int v) {
std::this_thread::sleep_for(std::chrono::seconds(2));
if (v == 2) asm("int $3");
std::this_thread::sleep_for(std::chrono::seconds(1));
printf("%d\n", v); // no sync here to keep it simple
}
int main() {
std::vector<std::thread> threads;
for (int i = 0; i < 4; i++) threads.emplace_back(f, i);
for (auto& thread : threads) thread.join();
return 0;
}
如果只停止线程，它仍应打印来自 2 以外的线程的消息，但情况并非如此，整个进程在打印任何内容之前停止（或在调试时触发断点）。在 Ubuntu 上，您收到的消息是：
跟踪/断点陷阱（核心转储）
【讨论】：