2012-08-15 46 views
3

我有應用程序(服務器)寫在C++幾小時左右崩潰,可能看起來很隨機。非常奇怪的GDB分段故障分析

最糟糕的是我試圖調試任何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地址,所以有線未映射到符號。

我需要做什麼來找到問題,調試該問題的內存轉儲。

感謝您的幫助!

+0

編譯時是否啓用GDB符號導出? 'gcc -g '或'g ++ -g '[有用的鏈接](http://www.seas.upenn.edu/cets/answers/gcc.html) – 2012-08-15 19:27:03

回答

1

開始gdb --core=core.668 selectserver固定的問題。

3

您需要使用調試符號編譯程序或獲取帶有調試符號的單獨文件。將-g標誌傳遞給gcc來啓用這些標誌。

如果你想看看所有的函數是什麼,即使是庫函數內部的函數(比如標準庫函數),你也需要獲得帶有調試符號的庫的一個版本。

+0

符號應用於selectserver可執行文件,但--symbols參數當gdb使用其他格式的參數啓動時,不讀這些數據,一切工作正常。 – Svisstack 2012-08-15 19:31:24

+0

@DirkHolsopple - 你完全搞錯了,用'-g'編譯*是*不需要獲得有意義的堆棧跟蹤符號名稱。 – 2012-08-16 06:48:46