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