Skip to content

How do you read a thread dump?

Level: 201 · anyone handed a stack trace for fifty threads

Stub — a question and its expected answers, not yet a lesson. No program behind this page has been written or run, so nothing on it has been through the check that backs every finished page. The table is what the finished lesson is expected to find, and every cell is unverified until a program prints it. (Not machine-checked here.)

One line: A thread dump is every thread's stack at one instant, and reading one is a matter of three questions — which threads are waiting, what are they waiting for, and who holds it — which Java's jstack answers in its own format, Go's SIGQUIT dump in another, and gdb's thread apply all bt in a third, and the page reads the same deadlock in all three.

The question

Detecting a deadlock got the dump; this page reads it. The same hung program, fifty threads: forty-eight idle in a pool, two deadlocked. The page shows each format abridged, marks the lines that matter, and gives the reading order — find the threads not in a known idle state, find their locks, find the cycle — then does the same for a hang that is not a deadlock: a thread blocked in a read that will never return.

What each language is expected to say

Expected answer, to be verified by the program
Rust lldb/gdb on the process, with the Rust frames' names
Go the SIGQUIT dump, with goroutine N [semacquire]: and [chan receive]: as the states to look for
C gdb -p, thread apply all bt, and info threads
C++ the same as C
Java jstack, with BLOCKED, WAITING, and the Found one Java-level deadlock section
Python faulthandler.dump_traceback_later or py-spy dump

What the programs have to show

  • the three dump formats for the same deadlock, abridged to the two threads and marked
  • the blocked-read hang in each, with the state that gives it away
  • the idle pool threads, and how each format shows nothing to see here

See also