Go process receiving SIGABRT or SIGSEGV signals is exiting with 2 exit status

[3v1n0]

Go version

go1.23.6

Output of go env in your module/workspace:

❯ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/marco/.cache/go-build'
GOENV='/home/marco/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/marco/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/marco/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/marco/go/pkg/mod/golang.org/[email protected]'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/marco/go/pkg/mod/golang.org/[email protected]/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.6'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/marco/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/DEV/authd/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3717024177=/tmp/go-build -gno-record-gcc-switches'

What did you do?

Having a simple go process around and signaling it (or itself) with SIGSEGV or SIGABRT makes the process to show the trace and then exit 2 exit status, instead of with the right signal exit code.

Or similar using:

package main

import (
	"os"
	"syscall"
	"time"
)

func main() {
	go func() {
		syscall.Kill(os.Getpid(), syscall.SIGSEGV)
	}()
	time.Sleep(10 * time.Second)
}

What did you see happen?

While having the trace can be useful, the process should then consistently exit in the same way it has been stopped, by calling the default handler for such signals.

In fact calling a go process from another C process, and doing

int status;
int exit_status = EXIT_FAILURE;
pid_t ret = waitpid (child_pid, &status, 0);

printf ("Waiting pid %d returned %d, "
          "exited: %d, signaled: %d", child_pid, ret,
          WIFEXITED (status), WIFSIGNALED (status));

if (ret == child_pid && WIFEXITED (status))
  {
    printf ("Exit status is %d\n", WEXITSTATUS (status));
    exit_status = WEXITSTATUS (status);
  }

For a go process that gets signaled we receive:

Waiting pid 277520, returned 277520, exited: 1, signaled: 0
Exit status is 2

And this is wrong because it makes impossible for the calling process to figure out what's the reason for the process being stopped (and react accordingly).

What did you expect to see?

The calling process should instead print Waiting pid 277520, returned 277520, exited: 0, signaled: 1 and WTERMSIG should provide the signal information.

This works well in fact when using SIGKILL or other signals that aren't handled by go by default.

[gabyhelp]

Related Issues

• runtime: cgo stuck because of go signal handler went into dead loop if pid=1 #59569
• os: Process.Exited returns false after exiting on signal #19798 (closed)
• gccgo: undocumented signal mask change #22723 (closed)
• src/runtime/signal_unix.go:202 Normal gameplay and subsequent code execution #67874 (closed)
• runtime: signal handling changed by signal.Notify #36420 (closed)
• os: process already finished, when sending syscall.SIGCONT #19314 (closed)
• runtime/cgo: incorrectly handle SIGPIPE(and other signals) from non-Go thread #56150 (closed)
• runtime: program panics if receive other signal #21008 (closed)
• Segfault when calling Go function from cgo signal handler #45499 (closed)
• os: process.Wait marks the process as already finished on ptrace stop signals on Linux #60321

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

[seankhliao]

This is a documented behaviour of the runtime package (exit 2 on crash).

[3v1n0]

Well even though that's documented I feel that's wrong and a bug to be planned.

And at least an env variable should be provided to define the exit code, given that 2 can be used by the program for other purposes.

[ianlancetaylor]

Unfortunately I don't think we can change this behavior now.