1
0
mirror of https://github.com/golang/go synced 2024-11-23 07:00:05 -07:00

sync: deflake TestWaitGroupMisuse3

Previous flakes:
https://build.golang.org/log/223365dedb6b6aa0cfdf5afd0a50fd433a16bade
https://build.golang.org/log/edbea4cd3f24e707ef2ae8378559bb0fcc453c22

Dmitry says in email about this:

> The stack trace points to it pretty clearly. Done can indeed unblock
> Wait first and then panic. I guess we need to recover after first
> Done as well.

And it looks like TestWaitGroupMisuse2 was already hardened against
this.  Do the same in TestWaitGroupMisuse3.

Change-Id: I317800c7e46f13c97873f0873c759a489dd5f47d
Reviewed-on: https://go-review.googlesource.com/19183
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This commit is contained in:
Brad Fitzpatrick 2016-02-03 16:58:43 +00:00
parent 0ed70efc6b
commit 03f42ee3a5

View File

@ -128,13 +128,16 @@ func TestWaitGroupMisuse3(t *testing.T) {
}
}()
defer runtime.GOMAXPROCS(runtime.GOMAXPROCS(4))
done := make(chan interface{}, 1)
done := make(chan interface{}, 2)
// The detection is opportunistically, so we want it to panic
// at least in one run out of a million.
for i := 0; i < 1e6; i++ {
var wg WaitGroup
wg.Add(1)
go func() {
defer func() {
done <- recover()
}()
wg.Done()
}()
go func() {
@ -150,8 +153,10 @@ func TestWaitGroupMisuse3(t *testing.T) {
wg.Wait()
}()
wg.Wait()
if err := <-done; err != nil {
panic(err)
for j := 0; j < 2; j++ {
if err := <-done; err != nil {
panic(err)
}
}
}
t.Fatal("Should panic")