Solaris上的堆栈回溯损坏

时间:2011-06-14 10:00:55

标签: stack solaris corrupt backtrace

有人可以解释为什么会发生以下损坏的堆栈跟踪吗?

Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libxnet.so.1...done.
Loaded symbols for /usr/lib/libxnet.so.1
Reading symbols from /usr/lib/libsocket.so.1...done.
Loaded symbols for /usr/lib/libsocket.so.1
Reading symbols from /usr/lib/libnsl.so.1...done.
Loaded symbols for /usr/lib/libnsl.so.1
Reading symbols from /usr/lib/libxml2.so.2...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /opt/csw/lib/libiconv.so.2...done.
Loaded symbols for /opt/csw/lib/libiconv.so.2
Reading symbols from /usr/lib/libcrypt_i.so.1...done.
Loaded symbols for /usr/lib/libcrypt_i.so.1
Reading symbols from /usr/lib/libpthread.so.1...
warning: Lowest section in /usr/lib/libpthread.so.1 is .dynamic at 00000074
done.
Loaded symbols for /usr/lib/libpthread.so.1
Reading symbols from /usr/lib/libm.so.2...done.
Loaded symbols for /usr/lib/libm.so.2
Reading symbols from /usr/lib/librt.so.1...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /usr/lib/libc.so.1...done.

warning: rw_common (): unable to read at addr 0x0

warning: sol_thread_new_objfile: td_ta_new: Debugger service failed
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libz.so.1...done.

warning: rw_common (): unable to read at addr 0x0

warning: sol_thread_new_objfile: td_ta_new: Debugger service failed
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libgen.so.1...done.

warning: rw_common (): unable to read at addr 0x0

warning: sol_thread_new_objfile: td_ta_new: Debugger service failed
Loaded symbols for /usr/lib/libgen.so.1
Reading symbols from /usr/lib/libaio.so.1...done.

warning: rw_common (): unable to read at addr 0x0

warning: sol_thread_new_objfile: td_ta_new: Debugger service failed
Loaded symbols for /usr/lib/libaio.so.1
Reading symbols from /usr/lib/libmd.so.1...done.

warning: rw_common (): unable to read at addr 0x0

warning: sol_thread_new_objfile: td_ta_new: Debugger service failed
Loaded symbols for /usr/lib/libmd.so.1
#0  0xfeb3487a in _malloc_unlocked () from /usr/lib/libc.so.1
(gdb) bt
#0  0xfeb3487a in _malloc_unlocked () from /usr/lib/libc.so.1
#1  0x210b5a68 in ?? ()
#2  0xfec0e5d0 in signames () from /usr/lib/libc.so.1
#3  0xfec0d000 in _sys_cldlist () from /usr/lib/libc.so.1
#4  0x08046a28 in ?? ()
#5  0xfeb34704 in _malloc_unlocked () from /usr/lib/libc.so.1
#6  0x00002008 in ?? ()
#7  0x210b5a68 in ?? ()
#8  0x21151b70 in ?? ()
#9  0xfeeda3b0 in ?? () from /usr/lib/libxml2.so.2
#10 0x08046a3c in ?? ()
#11 0xfee03c42 in xmlBufferCreateSize () from /usr/lib/libxml2.so.2
Previous frame inner to this frame (corrupt stack?)

核心来自在x86机器上构建的进程。 如果在执行该过程的机器上执行了回溯,则回溯是完美的,完整的 框架信息。 但是,如果我在构建机器(另一台机器)上使用核心进行回溯,我上面的跟踪。

我考虑的一个显而易见的事情是操作系统上的补丁级别不同 一个有5.10 Generic_138889-03(执行机器),另一个有5.10 Generic_138889-02(构建机器) 所以转数是关闭的。 这是原因吗?或者还有什么呢? 我可以做些什么来查看完整的帧信息,以便我更详细地检查核心内存?

会感激任何想法。

感谢。

1 个答案:

答案 0 :(得分:1)

确保在构建计算机上完全使用与执行该进程的计算机相同的共享库集。如果不是这种情况,请将流程从工作计算机使用的所有共享库复制到构建计算机上的文件夹,将LD_LIBRARY_PATH设置为此文件夹,启动gdb并再次运行bt

您可以在执行该过程的计算机上使用gdb中的info sharedlibraries命令获取的相关共享库的完整列表。