os/signal: TestSignal fails

[alberts]

What steps will reproduce the problem?

run the following for a few hours:

#!/bin/bash
set -xe
go test -c os/signal
while true; do
./signal.test -test.v -test.short -test.cpu 1,2,4
done

What is the expected output?

test passes always

What do you see instead?

=== RUN TestSignal
--- PASS: TestSignal (0.02 seconds)
signal_test.go:35: sighup...
signal_test.go:44: sigwinch...
signal_test.go:52: sigwinch...
signal_test.go:55: sigwinch...
=== RUN TestStress
--- PASS: TestStress (0.10 seconds)
=== RUN TestSignal-2
--- PASS: TestSignal-2 (0.00 seconds)
signal_test.go:35: sighup...
signal_test.go:44: sigwinch...
signal_test.go:52: sigwinch...
signal_test.go:55: sigwinch...
=== RUN TestStress-2
--- PASS: TestStress-2 (0.10 seconds)
=== RUN TestSignal-4
--- FAIL: TestSignal-4 (0.00 seconds)
signal_test.go:35: sighup...
signal_test.go:44: sigwinch...
signal_test.go:23: signal was user defined signal 1, want window changed
=== RUN TestStress-4
--- PASS: TestStress-4 (0.10 seconds)
FAIL

Which compiler are you using (5g, 6g, 8g, gccgo)?

6g

Which operating system are you using?

linux

Which version are you using?  (run 'go version')

go version devel +9742f722b558 Mon Mar 04 19:48:50 2013 -0800 linux/amd64

Please provide any additional information below.

takes a lot of runs to reproduce this

I've been able to reproduce this twice on a many-core machine. I can't imagine that some
outside force is sending SIGUSR1 to my Go tests, but I guess nothing is impossible...

[alberts]

Comment 1:

It reproduces pretty quickly if you strace the test. Example strace attached.
#!/bin/bash
set -xe
go test -c os/signal
while true; do
strace -f -v -tt -o/dev/shm/strace.log ./signal.test -test.v -test.short -test.cpu 1,2,4
done
I wonder if a signal from say cpu=2 leaks into the cpu=4 test?

Attachments:

1. strace.log (1186905 bytes)

[alberts]

Comment 2:

Reproduced this on a laptop without much else running, so I don't think it's a machine
issue.

[dvyukov]

Comment 3:

I was able to reproduce it once.
I think I understand what happens -- the signal simply slips from one test into another
(signal handler on a background thread (scavenger?) get preempted and rescheduled in the
subsequent test).
But reproduction rate is very low, I can't be sure.
Mailed:
https://golang.org/cl/7713043

[dvyukov]

Comment 4:

This issue was closed by revision fe01755.

Status changed to Fixed.