当一个线程在另一个线程中捕获异常后运行时，进程会使用 SIGABRT 中止

Process aborts with SIGABRT when a thread runs after exception is caught in another thread

本文关键字：线程 进程 运行时 中止 SIGABRT 一个 另一个 捕获异常      更新时间：2023-10-16

我有一个退出处理程序线程在等待工作线程完成其工作的条件。信号是从工作线程的析构函数完成的。

下面是退出处理程序线程的代码。

void Class::TaskExitHandler::run() throw()
{
while( ! isInterrupted() ) {
    _book->_eot_cond.wait(); // Waiting on this condition
    {
        CLASS_NAMESPACE::Guard<CLASS_NAMESPACE::FastLock> eguard(_book->_exitlist_lock);
        list<TaskGroupExecutor*>::const_iterator itr = _book->_exited_tasks.begin();
        for( ; itr != _book->_exited_tasks.end(); itr++ ) {
            (*itr)->join();
            TRACER(TRC_DEBUG)<< "Deleting exited task:" << (*itr)->getLoc() << ":"
                     << (*itr)->getTestID() << ":" << (*itr)->getReportName() << endl;
            delete (*itr);
        }
        _book->_exited_tasks.clear();
    }
    _book->executeAny();
}
}
}

现在，已经观察到的是，当工作线程捕获任何异常（从较低层引发）时，该线程将继续存在，并立即使用退出代码 134 进行内核，即 SIGABRT。

堆栈跟踪如下-

#0  0x0000005555f49b4c in raise () from /lib64/libc.so.6
#1  0x0000005555f4b568 in abort () from /lib64/libc.so.6
#2  0x0000005555d848b4 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib64/libstdc++.so.6
#3  0x0000005555d82210 in ?? () from /usr/lib64/libstdc++.so.6
#4  0x0000005555d82258 in std::terminate () from /usr/lib64/libstdc++.so.6
#5  0x0000005555d82278 in ?? () from /usr/lib64/libstdc++.so.6
#6  0x0000005555d81b18 in __cxa_call_unexpected () from /usr/lib64/libstdc++.so.6
#7  0x0000000120047898 in Class::TaskExitHandler::run ()
#8  0x000000012001cd38 in commutil::ThreadBase::thread_proxy ()
#9  0x0000005555c6e438 in start_thread () from /lib64/libpthread.so.0
#10 0x0000005555feed6c in __thread_start () from /lib64/libc.so.6
Backtrace stopped: frame did not save the PC

因此，似乎这个 run（） 函数指定它不会使用 "throw（）" 规范抛出任何异常，引发了一个异常（来自第 4 帧）。根据有关 __cxa_call_unexpected（） 的各种参考资料，堆栈跟踪描述了编译器在具有"throw（）"规范的函数中引发异常时中止的典型行为。我对问题的分析正确吗？

为了进行测试，我在此方法中添加了一个 try catch，并打印了异常消息。现在这个过程不是核心。异常消息与工作线程捕获的消息相同。我的问题是，这个线程如何访问另一个线程捕获的异常？它们是否共享一些与异常处理相关的数据结构？

请对此有所了解。这很令人费解..

注意：- 根据堆栈跟踪，调用 run（） 后立即引发call_unexpected。这加强了我对以某种方式共享异常堆栈或数据的怀疑。但没有找到任何关于这种行为的参考。

我将回答我自己的问题。在这种情况下发生的情况是在 TaskExitHandler 线程中调用了一个析构函数。此析构函数正在执行导致主线程中异常的相同操作。

由于 TaskExitHandler 线程被设计为不抛出（或者更确切地说是预期），因此没有 try-catch 块，因此在引发异常时进程中止。

由于析构函数的调用是隐式的，因此它从未显示在堆栈跟踪中，因此很难找到它。必须跟踪每个对象才能找到此异常泄漏。

感谢大家的积极参与:)这是我得到一些积极回应的第一个问题。

我会试一试 - 希望这能给你足够的继续你的研究。

我怀疑运行 TaskExitHandler 的线程是所有工作线程的父线程。 否则，TEH将很难与孩子们团聚。

子/工作线程不处理抛给它们的异常。 但是，必须在某处处理异常，否则整个过程将被关闭。 父线程（又名 TEH）是进程堆栈/链中用于处理异常的最后一站。 您的示例代码表明，TEH 的异常处理是简单地抛出/不处理异常。 所以它的核心。

它不一定是共享的数据结构，而是进程/线程 ID 和内存空间。 子线程确实与父线程以及彼此共享全局内存/堆空间，因此需要信号量和/或互斥体来锁定目的。

良好的封装要求工作线程应该足够智能，以处理它们可能看到的任何/所有异常。 这样，可以终止单个工作线程，而不是关闭父线程和进程树的其余部分。 OTW，您可以继续在TEH中捕获异常，但是线程实际上不太可能（或应该知道）如何处理异常。

如果以上不清楚，请添加评论，我很乐意进一步解释。

我做了一些研究，并确认异常是针对堆内存而不是堆栈内存生成的。 进程的所有线程共享相同的堆*，因此（至少对我来说）为什么父线程在子线程未捕获时会看到异常更有意义（至少对我来说）。 *FWIW，如果你分叉你的进程而不是启动一个新线程，你也会得到一个新的堆。 但是，分叉是对内存的昂贵操作，因为您还要将所有堆内容复制到新进程中。

此 SO 线程讨论了设置一个线程来捕获所有异常，这可能会引起人们的兴趣：从另一个线程捕获异常

相关文章：