"Thread Apply All Bt Full" Gives Blank in Gdb

thread apply all bt full gives blank in GDB

Try last GDB version. 7.1 or 7.2. Everything should work.

Getting a backtrace for inferior process at its exit

What's the best way to catch the exit in the inferior process and get a backtrace so I can see where the thread is exiting?

(gdb) catch syscall exit_group

Pruning backtrace output with gdb script

Using the links in Employed Russian's answer I was able to get something working. Here it is for posterity since it was completely non-obvious.

import gdb

# This loops through all the Thread objects in the process
for thread in gdb.selected_inferior().threads():

    # This is equivalent to 'thread X'
    thread.switch()       

    print "Thread %s" % thread.num

    # Just execute a raw gdb command
    gdb.execute('bt')

    framesNames = []
    f = gdb.newest_frame()
    while f is not None:
        framesNames.append(gdb.Frame.name(f))
        f = gdb.Frame.older(f)

    # do something with the name of each frame

If this were in a file named traces.py, then from gdb you can just execute the python:

source traces.py

There are other ways to invoke this python script too.

gdb backtrace with no user input?

Thanks to Aditya Kumar; acceptable solution:

gdb -batch -ex "run" -ex "bt" ${my_program} 2>&1 | grep -v ^"No stack."$

If the program needs arguments:

gdb -batch -ex "run" -ex "bt" --args ${my_program} param1 param2 \
                              param3 ... 2>&1 | grep -v ^"No stack."$

How to get more information about an exception using GDB?

When you see this output it is too late to find out what thread have thrown an exception because your program is already terminated. I guess what you need is to set catchpoint on std::out_of_range exception and continue running your program until this exception is thrown:

(gdb) catch throw out_of_range

When exception is thrown, gdb should stop and you can print backtrace of thread that causes an exception.

Why PMP (poor man's profiler) don't work on nginx?

The thread apply all bt does (surprise!) bt for each thread. It also stops as soon as there is any thread where bt results in an error (but that should not happen).

So if you attach to nginx by hand, then do info threads, and then keep repeating thread N and bt, you'll likely find a thread for which GDB can't produce a backtrace.

It might be interesting to know exactly what GDB prints for that thread.

You might also want to retry with the current version of GDB (7.2)

---

Related Topics