cmd/go: go tool seems to break shell suspend (^Z) with pprof -http

[prattmic]

Go version

go version go1.25.3 linux/amd64

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/usr/local/google/home/mpratt/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/usr/local/google/home/mpratt/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build707894335=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/usr/local/google/home/mpratt/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/usr/local/google/home/mpratt/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/google/home/mpratt/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.25.3.linux-amd64'
GOSUMDB='sum.golang.org'
GOTELEMETRY='on'
GOTELEMETRYDIR='/usr/local/google/home/mpratt/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='go1.25.3'
GOTOOLDIR='/usr/local/google/home/mpratt/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.25.3.linux-amd64/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.25.3'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

1. Generate a dummy pprof file to use as input (you can also use one you have laying around):

$ GOTOOLCHAIN=go1.25.3 go test -cpuprofile in.pprof bytes

2. Build a standalone version of cmd/pprof:

$ GOTOOLCHAIN=go1.25.3 go build cmd/pprof

3. Run pprof -http, and then suspend it with ^Z (Control + z). This should drop you back to the shell, at which point you can use fg to resume execution and then exit with ^C.

$ ./pprof -http=:8080 in.pprof 
Serving web UI on http://localhost:8080
^Z
$ fg
./pprof -http=:8080 in.pprof
^C
$

This is working as intended.

4. Now attempt the same thing through go tool:

$ GOTOOLCHAIN=go1.25.3 go tool pprof -http=:8080 in.pprof 
Serving web UI on http://localhost:8080
^Z

What did you see happen?

When run through go tool, the ^Z does not return control to the shell. It does still seem to suspend the process, as ^C and ^\ (SIGQUIT) have no effect. You need to run pkill -CONT pprof from another terminal to resume execution and regain the ability to exit pprof.

What did you expect to see?

Behavior should be the same when running through go tool as when running directly.

This reproduces with Go 1.25.3 and 1.24.9.

This reproduces with bash (GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)) and zsh (zsh 5.9 (x86_64-debian-linux-gnu)).

This was originally reported in #tools on Gopher Slack. Some additional findings there:

• Without any flags, pprof has its own mini-repl command line mode. In that mode, it ignores ^Z entirely (i.e., it does not suspend and keeps working). This behaves the same standalone or via go tool.

  • This is likely a result of some termios adjustments done for pprof's command line. It's possible that pprof -http does some or all of those termios adjustments.
  • For reference, Delve had similar ^Z ignored behavior, but wanted to support ^Z in its command line, which it did via pkg/terminal: support ctrlz for shell job control go-delve/delve#2806 and follow-up fix go-delve/liner@4726ab1.

• Surprisingly, adding an additional layer of indirection via the golang.org/dl wrappers fixes the problem?

$ go install golang.org/dl/go1.25.3@latest
$ go1.25.3 download
$ go1.25.3 tool pprof -http=:8080 in.pprof 
Serving web UI on http://localhost:8080
^Z
$ fg
go1.25.3 tool pprof -http=:8080 in.pprof
^C
$

[prattmic]

cc @golang/command-line @golang/runtime

[seankhliao]

maybe the same as #40467

[gabyhelp]

Related Issues

• cmd/go: `go tool` signal forwarding does not play nice with foreground tools #75152
• cmd/pprof: Control-C does not exit interactive mode #27147 (closed)
• cmd/pprof: go tool doesn't accept Ctrl-f while pprof does #37482 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ldemailly]

of note that I think you need

GOTOOLCHAIN=local

instead otherwise the indirection if not matching can cause it to work
(and have the go in the path be 1.24.9 or 1.25.3 as installed directly or with a symlink, not a go install'ed one)

[prattmic]

FWIW, my local toolchain is 1.24.8. Running the downloaded version via GOTOOLCHAIN=go1.25.3 does reproduce the issue for me.

[prattmic]

Looks like the exact same issue affects go tool trace -http. cmd/trace doesn't mess with the terminal in any mode, so my mentions of cmd/pprof doing so in some modes are likely a red herring.

[prattmic]

#75152 sounds relevant. I could imagine https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/tool/tool.go;l=375-381;drc=5f8fdb720c21873a8007b6c08aa9a5aee2125f76 being relevant.

How I could imagine this happening (I haven't verified!):

1. I believe ^Z sends SIGTSTP to the entire process group, so it is sent to cmd/pprof. cmd/pprof has no SIGTSTP signal handler, so the kernel immediately stops it.
2. cmd/go does have a SIGTSTP handler via signal.Notify(c) requesting all signals. So it receives the signal but does not stop.
3. The shell is waiting for the immediate child to stop (e.g., via waitpid(WUNTRACED)). Since cmd/go doesn't actually stop, the shell never returns control to the user.

This would explain why pprof needs a SIGCONT to start working again, but cmd/go never suspends. It would also explain why it works OK with the go1.25.3 wrapper: that wrapper is the immediate child and does not have a SIGTSTP handler.

If this is correct, then I think the fix would simply be for https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/tool/tool.go;l=375-381;drc=5f8fdb720c21873a8007b6c08aa9a5aee2125f76 to not request SIGTSTP. Since that is sent to the entire process group, there is no need to forward it.

[ianlancetaylor]

According to POSIX the following signals can be generated by the terminal and sent to all members of the process group:

• SIGHUP sent when the controlling terminal is closed
• SIGINT sent when the user types ^C on the terminal (by default, this is selectable using stty intr but I hope nobody does that)
• SIGQUIT sent when the user types ^\ on the terminal (selectable by stty quit)
• SIGTSTP sent when the user types ^Zon the terminal (selectable bystty susp`)
• SIGTTIN sent when a background process tries to read from the terminal
• SIGTTOU sent when a background process tries to write to the terminal

The go tool signal handling was added by https://go.dev/cl/282312. The CL description specifically calls out the case of sending SIGINT using os.Process.Signal, which will of course send the signal only to the cmd/go process, not to the process group.

So I suppose go tool should not try to catch SIGTSTP, SIGTTIN, SIGTTOU. Unfortunately as far as I know we have no way to enumerate the complete list of signals and then remove some. So another reasonable possibility would be that go tool only catches and forwards SIGHUP, SIGINT, SIGQUIT, and SIGTERM, as those are the signals most likely to be sent by some other program.