在多线程 C 程序中断言上的 gdb 断点答案

【问题标题】：gdb Breakpoint on assert on in multithreaded C program在多线程 C 程序中断言上的 gdb 断点
【发布时间】：2016-09-08 19:58:08
【问题描述】：

我正在使用来自<cassert> 的assert 来检查我的多线程C++11 程序中的不变量。当断言失败时，我希望能够在断言失败时检查失败函数的状态，以及仍然完整的回溯、变量状态等。问题似乎是SIGABRT 和我的线程之间的一些交互，因为我的std::threads 是pthread_killed，大概是由某些默认信号处理程序引起的。如何在断言失败时暂停 gdb？

以下是我尝试过的一些事情：

在SIGABRT 上设置一个捕捉点。这个问题确实发生了，但为时已晚（__pthread_kill）。
定义__assert_fail，即extern在<assert.h>中声明，并在其上设置gdb断点。这永远不会被捕获，所以大概在调用它之前 pthread 被杀死了 (?)。

这里推荐的方法是什么？

【问题讨论】：

@Klaus 感谢您的回答并感谢您的跟进。事实证明这是一个红鲱鱼，实际上真正的答案是根本不需要 gdb 的特殊配置。事实证明，我的 gdb 设置有一个不同的问题，我认为这是没有正确的断点/捕获点的问题，但它一直在工作。我会发布一个澄清的回应。如果有必要，您在断言代码中设置断点是正确的。

标签： c++ multithreading gdb

【解决方案1】：

我做了以下事情：

示例程序：

#include <cassert>
void f2()
{   
    assert(0);
}   

void f1()
{   
   f2();
}   

int main()
{   
    f1();
}

现在我将断点设置为 f2，希望以后可以使用stepi 降级到断言：

gdb > break f2
gdb > run
Breakpoint 11, f2 () at main.cpp:5
gdb > stepi // several times!!!!
0x080484b0 in __assert_fail@plt ()

啊！正如我们所见，stepi 转到符号，它告诉我们有一个具有该名称的函数。所以只需为__assert_fail@plt设置一个断点

gdb > break __assert_fail@plt
gdb > run
Breakpoint 11, f2 () at main.cpp:5

(gdb) bt
#0  0x080484b0 in __assert_fail@plt () 
#1  0x080485f7 in f2 () at main.cpp:5
#2  0x08048602 in f1 () at main.cpp:10
#3  0x0804861b in main () at main.cpp:15

为我工作！

【讨论】：

【解决方案2】：

如果您出于某种原因需要在 assert 上设置断点，Klaus 对 break on __assert_fail 的回答是绝对正确的。

然而，事实证明，在多线程程序的 gdb 中设置断点以查看堆栈跟踪根本没有必要，因为 gdb 已经在 SIGABRT 上中断并切换中止线程。就我而言，我有一组错误配置的库导致了这个红鲱鱼。如果您尝试使用多线程程序在 gdb 中查看中止代码 (SIGABRT) 的堆栈跟踪，则无需在 gdb 中执行任何操作，假设默认信号处理程序已就位。

仅供参考，您可以通过运行info signals 查看默认信号处理程序，通过运行info signals SIGABRT 可以查看SIGABRT。在我的机器上，我看到了这个，这表明程序将停止，等等。如果由于某种原因您的SIGABRT 信号处理程序没有设置为在SIGABRT 上停止，您需要更改该设置。更多信息请访问https://sourceware.org/gdb/onlinedocs/gdb/Signals.html。

(gdb) info signals SIGABRT
Signal        Stop  Print   Pass to program Description
SIGABRT       Yes   Yes Yes     Aborted

【讨论】：