Kulluk007 Kulluk007 - 1 month ago 10x
C++ Question

gdb Breakpoint on assert on in multithreaded C program

I'm using

to check invariants in my multithreaded C++11 program. When the assertion fails, I'd like to be able to inspect the state of the failing function, along with still-intact backtrace, variable state, etc. at the time of the failed assertion. The issue seems be some interaction between
and my threads, as my
s are
ed, presumably by some default signal handler. How can I pause gdb right at the time of the failed assertion?

Here are some things I've tried:

  1. set a catchpoint on
    . This catch does occur, but it's too late (in

  2. defined
    , which is
    declared in
    , and set a gdb breakpoint on it. This is never caught so presumably the pthread is being killed before this is called (?).

What's the recommended approach here?


If you need a breakpoint on assert for some reason, Klaus's answer to break on __assert_fail is absolutely correct.

However, it turns out that setting a breakpoint to see stack traces in gdb on multithreaded programs is simply not necessary at all, as gdb already breaks on SIGABRT and switches the the aborting thread. In my case I had a misconfigured set of libraries that lead to this red herring. If you are trying to see stack traces from aborted code (SIGABRT) in gdb using multithreaded programs, you do not need to do anything in gdb, assuming the default signal handlers are in place.

FYI, you can see the default signal handlers by running info signals, and the same for just SIGABRT by running info signals SIGABRT. On my machine, I see this, which shows that the program will be stopped, etc. If for some reason your SIGABRT signal handler is not set up to stop on SIGABRT, you need to change that setting. More info at https://sourceware.org/gdb/onlinedocs/gdb/Signals.html.

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