What does the traceback header `goroutine 84 [chan receive, 12 minutes]:` tell you about that goroutine?

## Anatomy of the header line Every goroutine in a traceback opens with a line of the form ``` goroutine 84 [chan receive, 12 minutes]: ``` There are three pieces of information in it, and each answers a different question. **`goroutine 84` — which one.** Goroutine ids come from a counter that only increases, and they are not reused: a fresh goroutine always gets a number nobody has had. So a low id was created early — `goroutine 1` is the goroutine running `main` — and a block of near-consecutive ids means those goroutines were created together, in a burst. The id is purely a runtime bookkeeping number: it is not an OS thread id, it means nothing outside the process, and Go deliberately offers no supported API to read your own. Its value to a reader is ordering and cross-referencing — a `created by ... in goroutine 17` line elsewhere in the dump points at a specific parent. **`chan receive` — where it is parked.** This is the *wait reason* the runtime recorded when it parked the goroutine. The vocabulary is small and worth knowing: | state | what it means | |---|---| | `running` | executing right now (in a crash dump, usually the goroutine that crashed) | | `runnable` | ready to run, waiting for a processor to pick it up | | `syscall` | blocked inside a system call on an OS thread | | `IO wait` | parked on the network poller, waiting for a socket to become readable or writable | | `chan receive` / `chan send` | blocked on a channel operation | | `select` | blocked in a `select` with no ready case | | `sleep` | inside `time.Sleep` | | `semacquire` | contending for a lock or waiting on a counter | | `GC assist wait` | throttled by the collector while it allocates | Parenthesised refinements appear too — `chan receive (nil chan)` tells you the channel operand was nil, which blocks forever by definition and is a completely different bug from a channel with no sender. A goroutine pinned to its thread prints `locked to thread`. **`12 minutes` — how long.** The runtime records when it parked the goroutine and adds the elapsed time to the header once the wait has run into minutes; short waits print no duration at all. This is the single most useful field in a large dump, because it converts a state into a judgment. Three hundred goroutines in `chan receive` is what a healthy idle worker pool looks like. Three hundred goroutines in `chan receive` for forty minutes, in a service whose queue is known to be busy, is a finding. ## The reading rule **A wait reason describes a location, not a fault.** Blocking is the normal condition of most goroutines in a long-lived Go program: workers wait for work, servers wait for connections, tickers sleep. Nothing in the header says whether that is correct. What makes a state interesting is the combination of the reason, the duration, the count of goroutines sharing it, and what the code is supposed to be doing at that moment. A candidate who says "they're blocked on a channel, that's the bug" has not read the dump; a candidate who says "they're blocked on a channel, which is expected — what is odd is that it has been forty minutes and there is no sender anywhere in this dump" has. ## Two distinctions people get wrong `IO wait` versus `syscall`. `IO wait` means the goroutine handed its file descriptor to the runtime's network poller and parked; no OS thread is tied up, and this is what a goroutine blocked reading a socket normally looks like. `syscall` means the goroutine is sitting inside a blocking system call on a real thread — ordinary file reads and `cgo` calls land here — and while it does, that thread is consumed. A hundred goroutines in `IO wait` is cheap; a hundred in `syscall` costs a hundred threads. `runnable` versus `running`. `running` means executing at the instant of the dump. `runnable` means the goroutine has work to do and is queued, waiting for a processor. A dump thick with `runnable` goroutines is a CPU-saturation signal, not a blocking one. Note also that in a crash dump a goroutine executing on another thread often cannot have its stack walked safely, and prints `goroutine running on other thread; stack unavailable` in place of frames.