As of Go 1.14 tip, runtime.throw enables slightly more diagnostic information in the traceback. It would help with debugging runtime crashes if it printed more diagnostics, such as:
FP/SP/and PC for all frames in all goroutines, not just the throwing goroutine (which doesn't even work if the throw happens on a system stack)
Runtime frames on all goroutines.
The *g of each goroutine. When a crash involves the scheduler or GC, we often see g pointers in arguments, but generally can't match these up to goroutines in the traceback.
Whether or not the world is stopped, or GC is running.
Most calls to runtime.throw are for internal runtime issues, but some of them are user errors that can't be caught and need to tear down the process (e.g., deadlocks, map races, out of memory). We probably want to distinguish these so the user errors don't include potentially confusing runtime-internal diagnostics.
As of Go 1.14 tip,
runtime.throw
enables slightly more diagnostic information in the traceback. It would help with debugging runtime crashes if it printed more diagnostics, such as:*g
of each goroutine. When a crash involves the scheduler or GC, we often see g pointers in arguments, but generally can't match these up to goroutines in the traceback.Most calls to
runtime.throw
are for internal runtime issues, but some of them are user errors that can't be caught and need to tear down the process (e.g., deadlocks, map races, out of memory). We probably want to distinguish these so the user errors don't include potentially confusing runtime-internal diagnostics./cc @mknyszek
The text was updated successfully, but these errors were encountered: