In a goroutine dump, what does the header `goroutine 4821 [chan send, 47 minutes]:` tell you?

## The anatomy of one block A `?debug=2` goroutine dump is a sequence of blocks, one per goroutine, in the same format the runtime prints when an unrecovered panic kills a process. A block looks like this: ``` goroutine 4821 [chan send, 47 minutes]: main.(*subscriber).push(0xc000112000, 0xc0001a4000) /srv/stream/subscriber.go:88 +0x7c main.(*server).streamLoop(0xc0000b4000, 0xc000112000) /srv/stream/server.go:142 +0x5e created by main.(*server).Subscribe in goroutine 61 /srv/stream/server.go:140 +0x11d ``` Everything you need to classify this goroutine is on the first line and the last. ## The id `4821` is the runtime's internal identifier for the goroutine. It is unique among live goroutines in this process and it is monotonic, so a high id means "created late" — mildly useful when you want to know whether a population of stuck goroutines is old or fresh. It is not an OS thread id: many goroutines share one thread and a goroutine may run on different threads over its life. It is also not stable across runs, and there is deliberately no exported API that accepts one. Its real use is cross-referencing *within the dump*: the `created by ... in goroutine 61` line lets you walk from a leaked goroutine back to the goroutine that spawned it, and from there up the chain. ## The state The word in brackets is the **wait reason** the runtime recorded when it parked this goroutine. The ones you meet constantly: - `chan send` — blocked trying to send on a channel whose buffer is full, or unbuffered with no receiver ready. - `chan receive` — blocked waiting for a value on a channel nobody has sent to. - `select` — blocked in a `select` where no case is ready and there is no `default`. - `IO wait` — parked in the runtime's network poller waiting for a socket to become readable or writable. This is the normal resting state of an idle connection handler, not a defect. - `sleep` — inside `time.Sleep`. - `syscall` — executing a blocking system call on its OS thread; a read of a regular file lands here, not in `IO wait`. - `running` / `runnable` — actually executing, or waiting for a P to run on. The state answers "what would have to happen for this goroutine to continue?" — a send needs a receiver, a receive needs a sender or a close, a `select` needs any one of its cases to become ready. That is the question you are really asking when you hunt a leak. ## The duration The `, 47 minutes` suffix is not always there, and the reason is deliberate. The runtime stamps a goroutine when it enters a waiting state, and when it prints a traceback it computes the elapsed time and includes it **only if the wait has exceeded roughly a minute**. Goroutines that are running, runnable, or that parked a few seconds ago show a bare state with no duration. That threshold makes the field a filter you get for free. Scan a dump for blocks that carry a minutes figure and you have narrowed a population of ten thousand goroutines down to the ones that have been stationary for longer than any request in your service takes. Two cautions. First, it is a coarse figure in whole minutes, not a precise measurement. Second — and this is where people go wrong — a long wait is *not* the same as a leak. An idle worker parked on `chan receive` for six hours because there was no work is behaving exactly as designed; so is an accept loop and so is a background ticker. Duration narrows the field; it does not convict. ## The frames and the created-by line Under the header come the stack frames, innermost call first, each with its file, line and instruction offset. The hexadecimal arguments printed beside a function name are the raw argument words as the runtime saw them; they are occasionally useful and often misleading after inlining, so do not build an argument on them. The final `created by <function> in goroutine <id>` line is the one people underuse. It names the function that executed the `go` statement, and the goroutine that executed it. When a dump contains four thousand blocks with byte-identical stacks, that line is what turns "something is leaking" into "the writer goroutine started for each subscriber is leaking", which is a fixable statement. ## Reading a population, not a goroutine The skill this question is really testing is whether you read the dump as a census. One block tells you almost nothing. Four thousand blocks that share a stack, share a `chan send` state, all carry a minutes figure and all trace back to the same `created by` line tell you precisely where to look — and the last frame before the park tells you which channel is never being drained.