In looking at examples for #21165, I noticed an unchecked overflow in the syscall package on the nacl platform.

The queue implementation in syscall/net_nacl.go waits on the difference q.w-q.r, and the read and write methods of byteq and msgq increment those variables without checking for overflow. w and r both have type int, so on a 32-bit build it is quite possible to overflow one or the other and cause the reader and/or writer to deadlock.

This program times out due to the deadlock: https://play.golang.org/p/C_YmUjwXwW
In contrast, stopping the reader just before the overflow causes the program to exit successfully: https://play.golang.org/p/XPEU7FoTes

The difference between the two is just one iteration of the loop: the one that tips the writer across that overflow:

-		for n < maxInt {
+		for n+bufSize < maxInt {

(Proposal #19624 would report the overflow here instead of deadlocking the program.)