2

In the Linux message file, I notice that a segfault is reported for process 14947, but I did not get the core dump for process 14947, instead I got 14069.core.(Its generated time matches the time the segfault is hit).

Then I use gdb and find:-

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]

When I run "info thread", I get:-

(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 ()

So here goes my questions:-

  1. Why the coredump file name does not match the segfault process id in the message file?
  2. I think the coredump is for a particular process, why there are so many info like "[New process 26130]" here ?
  3. why "info thread" will display the info for process, not thread?

Thanks!

Plus: My OS is RHEL5.

4

1 に答える 1

2

Linux では、カーネル スレッドは単なる軽量プロセス (仮想メモリがコピー オン ライトとしてマークされるのではなく、親プロセスと共有されるとマークされるプロセス) であるため、一覧表示されるプロセス ID は、スレッド ID。これは単なる推測ですが、おそらくコアの ID はシグナルを処理したスレッドと同じであり、メイン スレッドとは異なる可能性があります。

于 2012-12-12T03:33:15.343 に答える