gdb本身的coredump

wenming_1011

程序产生了一个core dump，想用gdb去调试看问题出在什么地方，但是
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)
奇怪的事情发生了，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

程序产生coredump，如果系统ulimit允许，会产生core文件。
用gdb直接打开这个core文件，并且加载符号表，就可以直接显示堆栈信息和死机的位置。以及当时的变量值。

你要是用gdb直接执行程序的话，可能是你的多线程导致gdb coredump了。

emmoblin

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

参考

wenming_1011

你说的出错位置是这里吗？
#0  0xffffe410 in __kernel_vsyscall ()
而堆栈信息又从哪里看呢？

wenming_1011

还是自己来回答，也希望有人遇到和我一样的问题能借鉴。gdb里先用list，再用bt或where看出错的地方就不会报coredump了！知其然不知其所以然。不知道为什么使用list之后gdb就不会出coredump了。

MMMIX

原帖由 wenming_1011 于 2009-12-17 15:33 发表
还是自己来回答，也希望有人遇到和我一样的问题能借鉴。gdb里先用list，再用bt或where看出错的地方就不会报coredump了！知其然不知其所以然。不知道为什么使用list之后gdb就不会出coredump了。

这个指定是 GDB 的 bug。

wolf5729

你是不是在源码里定义了一个占用字节数很大的数组？
比如，static int iArray[1024000000];
如果一个程序编译期确定下的变量使用的内存大于ulimit的软限制或硬限制，程序是起不来的。