Question

我有一些我以前从未见过的回溯。参见这些主题中的第2帧：

Thread 31 (process 8752):
#0  0x00faa410 in __kernel_vsyscall ()
#1  0x00b0b139 in sigprocmask () from /lib/libc.so.6
#2  0x00b0c7a2 in abort () from /lib/libc.so.6
#3  0x00752aa0 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6
#4  0x00750505 in ?? () from /usr/lib/libstdc++.so.6
#5  0x00750542 in std::terminate () from /usr/lib/libstdc++.so.6
#6  0x00750c65 in __cxa_pure_virtual () from /usr/lib/libstdc++.so.6
#7  0x00299c63 in ApplicationFunction()

Thread 1 (process 8749):
#0  0x00faa410 in __kernel_vsyscall ()
#1  0x00b0ad80 in raise () from /lib/libc.so.6
#2  0x00b0c691 in abort () from /lib/libc.so.6
#3  0x00b4324b in __libc_message () from /lib/libc.so.6
#4  0x00b495b6 in malloc_consolidate () from /lib/libc.so.6
#5  0x00b4b3bd in _int_malloc () from /lib/libc.so.6
#6  0x00b4d3ab in malloc () from /lib/libc.so.6
#7  0x08147f03 in AnotherApplicationFunction ()

当用gdb打开它并获得回溯它给我线程1.后来我看到了线程31所处的奇怪状态。这个线程来自我们遇到问题的库，所以我认为崩溃是由它

那是什么意思？两个线程同时做违法的事情？或者它是其中之一，在另一个中导致某种程度的abort（）？

操作系统是Linux Red Hat Enterprise 5.3，它是一个多处理器服务器。

Answer 1

很难确定，但是我第一次怀疑看到这些堆栈跟踪会导致内存损坏（可能是堆上的缓冲区溢出）。如果是这种情况，则损坏可能是两个线程最终都在abort中的根本原因。

你可以valgrind你的应用吗？

Answer 2

看起来它可能是由线程1中的malloc检测到的堆损坏，导致或由线程31中的错误引起。

一些代码覆盖a.o.线程31中的vtable很容易导致这种情况。

Answer 3

线程31中止的原因可能是因为它以某种方式破坏了应用程序堆。然后，当主线程尝试分配内存时，堆数据结构处于错误状态，导致分配失败并再次中止应用程序。

两个线程同时中止（）

3 个答案: