c++ - 所有线程在核心转储文件中等待，但有人触发了 SIG_ABRT

Question

我多年来一直支持用 C++ 编写的应用程序，但最近它开始崩溃，提供我们不知道如何处理的核心转储。 它在 Ubuntu 14.04.5 上的设备上运行

在 GDB 中加载核心文件时，它说: 程序以信号 SIGABRT 终止，已中止

我可以检查 230 个线程，但它们都在完全相同的内存位置的 wait() 中。

有一个 ID 为 1 的线程在理论上可能是负责的，但该线程也在等待中。

所以我基本上有两个问题。

线程的id索引是如何工作的？ GDB ID 为 1 的线程是最后一个事件线程吗？或者是任意索引并且失败可以在任何其他线程中？

当一个 SIGABRT 被触发时，所有的线程如何都在 wait() 中？ 当操作系统决定介入停止进程时，指令指针不应该位于失败的命令处吗？还是某种死锁保护？

非常感谢任何帮助。

线程1的回溯:

#0  0xf771dcd9 in ?? ()
#1  0xf74ad4ca in _int_free (av=0x38663364, p=<optimized out>,have_lock=-186161432) at malloc.c:3989
#2  0xf76b41ab in std::string::_Rep::_M_destroy(std::allocator<char> const&) () from /usr/lib32/libstdc++.so.6
#3  0xf764f82f in operator delete(void*) () from /usr/lib32/libstdc++.so.6
#4  0xf764f82f in operator delete(void*) () from /usr/lib32/libstdc++.so.6
#5  0x5685e8b4 in SlimStringMapper::~SlimStringMapper() ()
#6  0x567d6bc3 in destroy ()
#7  0x566a40b4 in HttpProxy::getLogonCredentials(HttpClient*, HttpServerTransaction*, std::string const&, std::string const&, std::string&, std::string&) ()
#8  0x566a5d04 in HttpProxy::add_authorization_header(HttpClient*, HttpServerTransaction*, Hosts::Host*) ()
#9  0x566af97c in HttpProxy::onClientRequest(HttpClient*, HttpServerTransaction*) ()
#10 0x566d597e in callOnClientRequest(HttpClient*, HttpServerTransaction*, FastHttpRequest*) ()
#11 0x566d169f in GateKeeper::onClientRequest(HttpClient*, HttpServerTransaction*) ()
#12 0x566a2291 in HttpClientThread::run() ()
#13 0x5682e37c in wa_run_thread ()
#14 0xf76f6f72 in start_thread (arg=0xec65ab40) at pthread_create.c:312
#15 0xf75282ae in query_module () at ../sysdeps/unix/syscall-template.S:82
#16 0xec65ab40 in ?? ()

另一个应该等待的线程:

#0  0xf771dcd9 in ?? ()
#1  0x5682e37c in wa_run_thread ()
#2  0xf76f6f72 in start_thread (arg=0xf33bdb40) at pthread_create.c:312
#3  0xf75282ae in query_module () at ../sysdeps/unix/syscall-template.S:82
#4  0xf33bdb40 in ?? ()

最好的问候 乔恩

Answer 1

How can all threads be in wait() when a SIGABRT is triggered?

wait 是 POSIX 函数，还是来自运行时环境的函数？您在查看更高级别的回溯吗？

无论如何，有一个简单的解释为什么会发生这种情况:SIGABRT 被发送到进程，而不是由线程以同步方式生成。也许同事在观察到死锁后发出了创建 coredump 的信号，以收集证据以供将来分析？