gdb本身的coredump

wenming_1011

程序產(chǎn)生了一個(gè)core dump，想用gdb去調(diào)試看問題出在什么地方，但是
gdb executable -c core

Loaded symbols for /export/home/lss/lib/libcfg1.so
Core was generated by `executable'.
Program terminated with signal 6, Aborted.
[New process 27818]
[New process 19639]
[New process 28272]
[New process 28188]
[New process 27836]
[New process 27831]
[New process 27829]
[New process 27828]
[New process 27827]
#0  0xffffe410 in __kernel_vsyscall ()
(gdb)bt(where)
奇怪的事情發(fā)生了，gdb自己core dump了！
#11 <signal handler called>
#12 0xf73ae04c in _int_free () from /lib/libc.so.6
#13 0xf73ae9d9 in free () from /lib/libc.so.6
#14 0xf799afa1 in operator delete () from /usr/lib/libstdc++.so.6
Memory fault(coredump)

[ 本帖最后由 wenming_1011 于 2009-12-15 09:45 編輯 ]

wenming_1011

自己up

emmoblin

程序產(chǎn)生coredump，如果系統(tǒng)ulimit允許，會產(chǎn)生core文件。
用gdb直接打開這個(gè)core文件，并且加載符號表，就可以直接顯示堆棧信息和死機(jī)的位置。以及當(dāng)時(shí)的變量值。

你要是用gdb直接執(zhí)行程序的話，可能是你的多線程導(dǎo)致gdb coredump了。

emmoblin

http://hi.baidu.com/hatmann1944/ ... a9b7cca7ef3f82.html

參考

wenming_1011

你說的出錯(cuò)位置是這里嗎？
#0  0xffffe410 in __kernel_vsyscall ()
而堆棧信息又從哪里看呢？

wenming_1011

還是自己來回答，也希望有人遇到和我一樣的問題能借鑒。gdb里先用list，再用bt或where看出錯(cuò)的地方就不會報(bào)coredump了！知其然不知其所以然。不知道為什么使用list之后gdb就不會出coredump了。

MMMIX

原帖由 wenming_1011 于 2009-12-17 15:33 發(fā)表
還是自己來回答，也希望有人遇到和我一樣的問題能借鑒。gdb里先用list，再用bt或where看出錯(cuò)的地方就不會報(bào)coredump了！知其然不知其所以然。不知道為什么使用list之后gdb就不會出coredump了。

這個(gè)指定是 GDB 的 bug。

wolf5729

你是不是在源碼里定義了一個(gè)占用字節(jié)數(shù)很大的數(shù)組？
比如，static int iArray[1024000000];
如果一個(gè)程序編譯期確定下的變量使用的內(nèi)存大于ulimit的軟限制或硬限制，程序是起不來的。