Go Panic with Full Goroutine Dump (log)
A Go panic followed by the runtime's full goroutine dump — four goroutines with their wait states, two-line frames and a created by attribution, separated by blank lines. Blank-line separation defeats multi-line rules that treat an empty line as the end of an event.
2026/03/17 09:14:41 inventory: reserving 3 skus for order ord-2026-0317-004182
panic: reserve: sku SKU-88213 not found
goroutine 41 [running]:
github.com/example/shop/inventory.(*Reserver).Reserve(0xc0000b4000, {0xc0001a2000, 0x3})
/src/inventory/reserve.go:88 +0x1a4
github.com/example/shop/inventory.handleReserve({0x8f2c40, 0xc0000f6000}, 0xc0001b8100)
/src/inventory/http.go:41 +0xc8
goroutine 1 [chan receive, 12 minutes]:
main.main()
/src/cmd/inventory/main.go:61 +0x1f4
goroutine 19 [select, 12 minutes]:
database/sql.(*DB).connectionOpener(0xc0000d2000, {0x8f2c78, 0xc0000c0140})
/usr/local/go/src/database/sql/sql.go:1246 +0x8d
created by database/sql.OpenDB in goroutine 1
/usr/local/go/src/database/sql/sql.go:824 +0x14b
goroutine 42 [IO wait]:
internal/poll.runtime_pollWait(0x7f4a1c0b2e18, 0x72)
/usr/local/go/src/runtime/netpoll.go:345 +0x85
exit status 2
Specifications
- Lines
- 22
- Goroutines
- 4
- Panic Message
- reserve: sku SKU-88213 not found
- Blank Line Separated
- true
- Exit Status
- 2
- Frame Pattern
- function(args) then tab-indented file:line +offset
Testing contract
Expected to pass- Scenario
- Group the dump into one event and extract the panicking goroutine.
- Expected result
- All four goroutines stay in a single event despite the blank separators, and goroutine 41 is identified as the running one whose frames carry the panic.
What is a .log file?
LOG files are plain-text records of events emitted by software, typically one entry per line with a timestamp, severity, and message. There is no single standard, so formats range from unstructured text to structured JSON lines. They are central to debugging, monitoring, and auditing.
How to use this file
Use an example LOG file to test log parsers, timestamp and severity extraction, line-oriented streaming, and ingestion into monitoring or analysis pipelines.
How to use this file for testing
“Go Panic with Full Goroutine Dump (log)” is a deterministic Novus Examples fixture for Observability, Log parsing, Error handling. Structured and plain-text telemetry with known timestamps, levels, request identifiers, and error states for testing log ingestion, correlation, dashboards, and alert pipelines.
Documented properties for this file: LOG · 879 bytes. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Telemetry fixtures use fixed trace IDs, span IDs, and timestamps so ingestion is reproducible run to run. Point your collector, parser, or query layer at the file and assert the documented span tree, metric families, or severity mix; service and host names are invented.
Code examples
grep -i error go-panic-goroutine-dump.log | head
awk '{print $1, $2, $NF}' go-panic-goroutine-dump.log | headRelated files
- logPlain-Text Log — Multi-Line Events Needing Line Joining (log)A Spring-style text log where two stack traces span many physical lines. Eight logical events across a larger number of lines, so a shipper's multi-line rule — anything not starting with a timestamp continues the previous event — can be scored against a known answer.
- logPlain-Text Log — No Trailing Newline on the Last Line (log)Four log lines where the last has no terminating newline — the normal state of any file still open for append. A tailer that only emits on seeing a newline holds that fourth line forever, which is why the newest error is the one missing from the dashboard.
- jsonlStructured Log — Blank, Non-JSON and BOM-Prefixed Lines (jsonl)A JSON Lines file with the debris a real container stream carries: blank and whitespace-only lines, one bare stderr write from a C library, a mid-file byte-order mark and two lines that are valid JSON but not objects. Five real records are in there.
- jsonlStructured Log — Clock Skew Across Three Hosts (jsonl)Three hosts writing to one stream with disagreeing clocks: one 45 seconds behind and one six hours ahead because NTP is unreachable. Interleaved by host, so a naive tail shows events from the future and a retention window silently drops the past.
- jsonlStructured Log — Multi-Line Stack Traces Inside JSON (jsonl)Java, Python and Go stack traces carried inside JSON string fields with their newlines escaped — the shape a structured logger produces, and the one that defeats multi-line joining rules written for plain text. Includes a Caused by chain and a goroutine dump.
- jsonlStructured Log — Truncated Final Record, Intentionally Corrupt (jsonl)Twelve complete JSON records followed by a thirteenth cut off after 96 bytes with no trailing newline, exactly as a container log looks when the process is killed mid-write. Intentionally corrupt and small: a tailer must hold the partial line for a continuation rather than emit or discard it.
Generated by generation/observability.py. Free for any use, no attribution required — license.