This is a regression in defer behavior for 1.14 for programs that do repeated panics, recovers, and re-panics (which could be because of a recursive, interpreter-like function). The actual fix is fairly simple, so it would be good to get this into 1.14.1.
…ver/re-panics and open-coded defers
In the open-code defer implementation, we add defer struct entries to the defer
chain on-the-fly at panic time to represent stack frames that contain open-coded
defers. This allows us to process non-open-coded and open-coded defers in the
correct order. Also, we need somewhere to be able to store the 'started' state of
open-coded defers. However, if a recover succeeds, defers will now be processed
inline again (unless another panic happens). Any defer entry representing a frame
with open-coded defers will become stale once we run the corresponding defers
inline and exit the associated stack frame. So, we need to remove all entries for
open-coded defers at recover time.
The current code was only removing the top-most open-coded defer from the defer
chain during recovery. However, with recursive functions that do repeated
panic-recover-repanic, multiple stale entries can accumulate on the chain. So, we
just adjust the loop to process the entire chain. Since this is at panic/recover
case, it is fine to scan through the entire chain (which should usually have few
elements in it, since most defers are open-coded).
The added test fails with a SEGV without the fix, because it tries to run a stale
open-code defer entry (and the stack has changed).
Run-TryBot: Dan Scales <email@example.com>
TryBot-Result: Gobot Gobot <firstname.lastname@example.org>
Reviewed-by: Keith Randall <email@example.com>
(cherry picked from commit fae87a2)
Run-TryBot: Dmitri Shuralyov <firstname.lastname@example.org>