Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

proposal: runtime: add a default, non-destructive signal handler that creates a stack dump #64687

Open
kgibm opened this issue Dec 12, 2023 · 2 comments
Open

proposal: runtime: add a default, non-destructive signal handler that creates a stack dump #64687

kgibm opened this issue Dec 12, 2023 · 2 comments
Labels
Proposal
Milestone
Proposal

Comments

@kgibm
Copy link

kgibm commented Dec 12, 2023

Proposal Details

By default, Go produces a stack dump and exits on various signals:

A SIGQUIT, SIGILL, SIGTRAP, SIGABRT, SIGSTKFLT, SIGEMT, or SIGSYS signal causes the program to exit with a stack dump.

It is commonly desired to create such a stack dump using a mechanism such as a signal but without exiting. Such thread dumps may be used to investigate hangs or as a rudimentary sampling profiler. Such built-in handlers are common in other languages such as Java (e.g. using SIGQUIT).

One way for a program to handle this requirement is to handle a signal such as SIGUSR1, generate a stack dump by calling pprof.Lookup on the goroutine profile and then write that to a file with Profile.WriteTo.

Alternatively, native debuggers and tools such as pstack may be used but they generally lack the detail of Go stack dumps.

This proposal is for Go to have a built-in signal handler that non-destructively writes a thread dump to stderr in response to a signal such as SIGUSR2. This would be a behavior change that may cause unintended side effects for any programs that already have a SIGUSR2 handler.
@kgibm kgibm added the Proposal label Dec 12, 2023
@gopherbot gopherbot added this to the Proposal milestone Dec 12, 2023
@bcmills
Copy link
Contributor

bcmills commented Dec 12, 2023

In theory you could build this as a library using runtime.Stack and signal.Notify.

@seankhliao seankhliao changed the title Proposal: os/signal: Add a default, non-destructive signal handler that creates a stack dump proposal: os/signal: Add a default, non-destructive signal handler that creates a stack dump Dec 12, 2023
@seankhliao seankhliao changed the title proposal: os/signal: Add a default, non-destructive signal handler that creates a stack dump proposal: runtime: Add a default, non-destructive signal handler that creates a stack dump Dec 12, 2023
@seankhliao seankhliao changed the title proposal: runtime: Add a default, non-destructive signal handler that creates a stack dump proposal: runtime: add a default, non-destructive signal handler that creates a stack dump Dec 12, 2023
@mauri870
Copy link
Member

mauri870 commented Dec 12, 2023 •
edited

I also think this is fairly simple to implement in a separate package, and one might depend on different conditions for it to trigger. Here we are discussing signal handlers, but maybe someone else wants to create a dump when memory reaches a certain threshold, or some other condition is reached. I like the idea of a general api involving runtime.Stack that is triggered by some custom condition and writes to a io.Writer of choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Proposal
Projects
Proposals
Status: Incoming
Milestone
Proposal
Development

No branches or pull requests
4 participants
@bcmills @kgibm @gopherbot @mauri870