Segfault 进程 id 和核心转储进程 id 不同。为什么？答案

【问题标题】：Segfault process id and core dump process id are different. Why?Segfault 进程 id 和核心转储进程 id 不同。为什么？
【发布时间】：2012-12-12 03:11:10
【问题描述】：

在 Linux 消息文件中，我注意到进程 14947 报告了段错误，但我没有得到进程 14947 的核心转储，而是得到了 14069.core。（它的生成时间与命中段错误的时间相匹配)。

然后我使用 gdb 并找到：-

Program terminated with signal 11, Segmentation fault.
[New process 14947]
[New process 26131]
[New process 26130]
[New process 26129]
[New process 26128]
[New process 14945]
[New process 14842]
[New process 14726]
[New process 14598]
[New process 14069]

当我运行“信息线程”时，我得到：-

(gdb) info thread
10 process 14069  0xffffe410 in __kernel_vsyscall ()
9 process 14598  0xffffe410 in __kernel_vsyscall ()
8 process 14726  0xffffe410 in __kernel_vsyscall ()
7 process 14842  0xffffe410 in __kernel_vsyscall ()
6 process 14945  0xffffe410 in __kernel_vsyscall ()
5 process 26128  0xffffe410 in __kernel_vsyscall ()
4 process 26129  0xffffe410 in __kernel_vsyscall ()
3 process 26130  0xffffe410 in __kernel_vsyscall ()
2 process 26131  0xffffe410 in __kernel_vsyscall ()
* 1 process 14947  0x006a8300 in pthread_mutex_lock ()

所以我的问题是：-

为什么 coredump 文件名与消息文件中的 segfault 进程 ID 不匹配？
我认为 coredump 是针对特定进程的，为什么这里有这么多诸如“[新进程 26130]”之类的信息？
为什么“信息线程”会显示进程信息，而不是线程信息？

谢谢！

另外：我的操作系统是 RHEL5。

【问题讨论】：

我真的不知道，但也许这与 Linux 线程是具有自己 id 的进程有关....至少我一直记得它是这样的。
向我们展示产生此分段错误的程序。
@Eric Leschinski 抱歉，Eric，我无法在此处粘贴代码，并且没有可用于二进制文件的符号。更糟糕的是，堆栈也已损坏。不知道如何分配部分代码引入了这个问题。

标签： c++ linux gdb segmentation-fault

【解决方案1】：

在 Linux 中，内核线程只是轻量级进程（虚拟内存被标记为与父进程共享而不是标记为写时复制的进程），因此您看到列出的进程 ID 是与线程 ID 相同。这只是一个猜测，但可能内核的 ID 与处理信号的线程相同，而主线程可能与主线程不同。

【讨论】：