testing/synctest: prevent isolation failures via WaitGroup [freeze exception]

[neild]

cc @golang/release

This is a freeze exception request for https://go.dev/cl/674795.

The new synctest package distinguishes between goroutines which are "durably blocked" and merely blocked. A durably blocked goroutine is blocked, and can only be unblocked by another goroutine in its "bubble".

In almost all cases, synctest takes steps to ensure that a durably blocked goroutine cannot be woken from outside its bubble. For example, attempting to wake a goroutine blocked on sync.Cond.Wait from outside its bubble causes a panic. (https://go.dev/cl/675617 makes the sync.Cond panic a fatal panic, since otherwise the runtime is left in an inconsistent state. I think that's a bugfix and doesn't require a freeze exception, though.)

The one place I know of where a durably blocked goroutine can be woken from outside its bubble is via a WaitGroup. WaitGroup.Wait is durably blocking, but nothing prevents a goroutine from outside a waiter's bubble from waking it with WaitGroup.Done.

CL 674795 closes this gap by associating WaitGroups with bubbles, in the same way that we associate channels with bubbles. Since WaitGroup does not have a constructor, association happens on the first call to Add. Wait is durably blocking if and only if the WaitGroup is associated with the waiter's bubble. Calling Add or Done on a WaitGroup associated with a bubble from outside that bubble panics.

[gabyhelp]

Related Issues

• testing/synctest: isolation failure in encoding/json #73733 (closed)

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

[mknyszek]

In the weekly release meeting, we don't think this needs a freeze exception. It's fixing an issue in a new feature, polishing it. This is within the scope of the freeze. Approved.

[neild]

Fixed in https://go.dev/cl/676656.