Одновременное прерывание () в двух потоках

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

Возможно, что поток 31 прервался из-за того, что он каким-то образом уничтожил кучу приложения.Затем, когда основной поток попытался выделить память, структура данных кучи находилась в плохом состоянии, что привело к сбою выделения и повторному завершению приложения.

Answer 3

Похоже, что это может быть повреждение кучи, обнаруженное malloc в потоке 1, вызванное или вызванное ошибкой в ​​потоке 31.

Какой-то сломанный кусок кода, перезаписывающий a.o. vtable в потоке 31 может легко вызвать это.