If I use go test -c to compile a test binary, than I seem to always get a stack dump on SIGQUIT, for 1.10, 1.11rc1, and tip.

I don't fully understand what's going on here, but it seems related to the call to base.StartSigHandlers in cmd/go/internal/test/test.go:

which seems to swallow SIGQUIT:

If I change the file to include a test that calls t.Log, then I seem to be able to get a stack dump with tip, but not with 1.10 or 1.11rc1

Possibly related to #24929?

I played around with this a little more last night. My current repro case is a little simpler than the top post. Here's my test file:

package a_test

import (
	"testing"
	"time"
)

func TestSleep(t *testing.T) {
	time.Sleep(20 * time.Second)
}

And then in bash I run this one-liner rather than manually sending SIGQUIT: go test . & sleep 2 && kill -QUIT % && wait. Note the single & to run go test in the background before sleeping for a second and then sending SIGQUIT to the go test process.

With either go version go1.12.3 darwin/amd64 or go version devel +5781df421e Tue Apr 16 20:27:15 2019 +0000 darwin/amd64, I get varying behavior where sometimes I get the full stack trace:

bash-3.2$ gotip test . & sleep 2 && kill -QUIT % && wait
[1] 45042
SIGQUIT: quit
PC=0x7fff5dc44a1e m=0 sigcode=0

goroutine 0 [idle]:
runtime.pthread_cond_wait(0x1241188, 0x1241148, 0x0)
<snip>
gs     0x0
FAIL	a/test	1.614s
[1]+  Exit 1                  /Users/mr/gotip/src/github.com/golang/go/bin/go test .

And other times it just silently quits:

gotip test . & sleep 2 && kill -QUIT % && wait
[1] 44939
[1]+  Exit 1                  /Users/mr/gotip/src/github.com/golang/go/bin/go test .

There doesn't seem to be any obvious reason why it sometimes prints a stack trace and sometimes doesn't. For a test that has minimal dependencies, sleep 2 seems to be plenty of time to actually be running the test executable, rather than during the background build.

The silent failure is particularly annoying when running a test suite that normally finishes quickly, seeing 10 seconds later that unexpectedly it hasn't finished and CPUs are idle, and then manually sending SIGQUIT only to have it silently exit without dumping the stack.

When you press ^\ or kill -QUIT the job SIGQUIT is sent to all processes, in this case both the cmd/go process and the test binary. The go tool installs a SIGQUIT handler that causes it to simply quit with an exit status of 1. Running go test builds the test binary and then runs it as a child, handling all its output so that the output can be cached. So I would guess that what is happening is that sometimes the subjob handling the test output runs first, and the output is sent to the terminal. Or, sometimes the SIGQUIT is seen first, and cmd/go exits without letting the subjob complete.