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>
}
}()
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() {
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")