Segfault進程標識和核心轉儲進程標識不同。爲什麼？

在Linux消息文件中，我注意到爲進程14947報告了一個段錯誤，但是我沒有得到進程14947的核心轉儲，而是獲得了14069.core。（它的生成時間與段錯誤的匹配時間相匹配）。Segfault進程標識和核心轉儲進程標識不同。爲什麼？

然後我用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]」在這裏？
爲什麼「info thread」會顯示進程的信息，而不是線程？

謝謝！

Plus：我的操作系統是RHEL5。

來源

2012-12-12 user1137890

我真的不知道，但也許它與Linux線程正在處理自己的ID ......至少這是我一直記得它的存在方式。 –

向我們展示產生此分段故障的程序。 –

@Eric Leschinski對不起，Eric，我不能在這裏粘貼代碼，並且沒有可用於二進制文件的符號。更糟糕的是，堆棧也被破壞。不知道如何分配代碼的一部分引入這個問題。 – user1137890

在Linux中，內核線程只是輕量級進程（虛擬內存被標記爲與父進程共享而不標記爲寫時拷貝的進程），因此您列出的進程ID是與線程ID相同。這只是一個猜測，但核心的ID可能與處理信號的線程相同，可能與主線程不同。

來源

2012-12-12 03:33:15

Segfault進程標識和核心轉儲進程標識不同。爲什麼？

回答

相關問題