runtime: include panic/throw logs in core dumps

[rhysh]

When a Go program crashes with GOTRACEBACK=crash, the OS creates a core dump. I'd like that core dump to include the human-readable "panic" or "fatal error" messages and stack traces—or at least the first N kB of them.

This could be done by writing the first ~64kB of errors and stack traces to a pre-allocated global slice in the runtime package in addition to writing to stderr.

No user code would be involved, so this is distinct from e.g. #16340. I'm particularly interested in being able to reliably collect not only "panic" crashes (from runtime.gopanic), but also "fatal error" crashes (from runtime.throw).

There are more tools being built around core dumps (#16410), so it would be good to collect all information relevant to crashes in that one place (#16410 (comment))

Alternatives include:

1. Adding an API that allows user code to set the fd that's used for panic/throw logs (Proposal: a sane, simple, Goish way to handle uncaught panics #16340 (comment)). This could end being a small change, though it would not catch problems with init functions in all packages.
2. Consult a new environment variable (like GORACE's log_path option) which would provide a prefix for the name of a file where the runtime would write out the crash report. The cost of adding a new environment variable is high, and it looks like this problem can be resolved without it.

[adg]

Seems fine to me. Anyone want to take a stab at implementing it?

[rhysh]

I've made an attempt at this which I'll mail momentarily. I can't say it's a good solution, but it's at least a starting point for discussion.

[gopherbot]

CL https://golang.org/cl/32013 mentions this issue.

[ianlancetaylor]

What else is there to do this for this issue now that https://golang.org/cl/32013 has been committed?

[rhysh]

Core dumps will now include text-formatted runtime messages from immediately before a crash; they don't include any text-formatted messages on the crashes themselves. We discussed in the CL how that could be recreated from the runtime package's datastructures in the core dump.

If that can become a requirement of the work for #16410, then this issue is ready to be closed since there won't be any more runtime changes required. Where should that request be tracked?

Thanks @ianlancetaylor

[ianlancetaylor]

Closing in favor of #16410. Thanks.