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

Question

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

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

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）进入内核。

stacktrace如下-

#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。这加强了我对异常堆栈或数据是否以某种方式共享的怀疑。但没有找到任何关于这种行为的参考。

Answer 1

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

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

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

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

Answer 2

我会尝试一下 - 希望这会给你足够的时间来继续你的研究。

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

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

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

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

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

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

这个 SO 线程讨论了设置一个线程来捕获所有异常，这可能会引起人们的兴趣： catching exceptions from another thread