c++ - GDBでの非常に奇妙なセグメンテーション違反分析

Question

数時間でクラッシュするアプリケーション（サーバー）が書かれC++ていますが、おそらくランダムに見えます。

core最悪の部分は、を使用してファイルのいずれかをデバッグしようとするとgdb、その結果が表示されます。

gdb --core=core.668 --symbols=selectserver
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Core was generated by `./selectserver'.
Program terminated with signal 11, Segmentation fault.
[New process 672]
[New process 671]
[New process 670]
[New process 669]
[New process 668]
#0  0xb7866896 in ?? ()
(gdb) info threads
  5 process 668  0xffffe410 in __kernel_vsyscall ()
  4 process 669  0xffffe410 in __kernel_vsyscall ()
  3 process 670  0xffffe410 in __kernel_vsyscall ()
  2 process 671  0xffffe410 in __kernel_vsyscall ()
* 1 process 672  0xb7866896 in ?? ()
(gdb) bt
#0  0xb7866896 in ?? ()
#1  0x082da4b0 in ?? ()
#2  0xb79e4252 in ?? ()
#3  0xa2ba9014 in ?? ()
#4  0x0825e14c in ?? ()
#5  0x082da4b0 in ?? ()
#6  0xb56175e8 in ?? ()
#7  0x00000080 in ?? ()
#8  0xb5fe723f in ?? ()
#9  0xa2ba9014 in ?? ()
#10 0xa2ba9008 in ?? ()
#11 0xb7a32ff4 in ?? ()
#12 0x00000000 in ?? ()
(gdb) thread 2
[Switching to thread 2 (process 671)]#0  0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7889486 in ?? ()
#2  0x00000000 in ?? ()
(gdb) thread 3
[Switching to thread 3 (process 670)]#0  0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7889486 in ?? ()
#2  0x00000000 in ?? ()
(gdb) thread 4
[Switching to thread 4 (process 669)]#0  0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7889486 in ?? ()
#2  0x00000000 in ?? ()
(gdb) thread 5
[Switching to thread 5 (process 668)]#0  0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb78b7de1 in ?? ()
#2  0x00000032 in ?? ()
#3  0xbf849ae8 in ?? ()
#4  0xbf8499e8 in ?? ()
#5  0x00000000 in ?? ()
(gdb) quit

何が起こっているのかわかりません。スタック上のアドレスを除い__kernel_vsyscallて、シンボルにマップされていないように配線されているのはなぜですか。

問題を見つけるために私がする必要があることは、その問題のメモリダンプをデバッグすることです。

手伝ってくれてありがとう！

Answer 1

デバッグシンボルを含むプログラムをコンパイルするか、デバッグシンボルを含む別のファイルを取得する必要があります。これらを有効にするには、-gフラグをgccに渡します。

すべての関数が何であるかを確認したい場合は、ライブラリ関数内の関数（たとえば、標準ライブラリ関数）も、デバッグシンボルを含むバージョンのライブラリを取得する必要があります。

Answer 2

gdb --core=core.668 selectserver修正された問題を開始します。