Accidentally clicked submit before I was done writing.

Fixing this is messy. I'm planning on adding support for conservative stack frames for preemption, but we could use the same thing for the parent of a sigpanic frame. That could fix the stack scanning problem.

But what if the defer grows the stack? That might still be okay combined with conservative scanning: stack copying will think x is live and will either update it (if it points to the stack), or not update it (if it points to the heap), but nothing can actually observe x, so both of these actions are harmless.

Will stack tracing solve this?

When it panics, the frame is essentially dead, except the variables captured by the defer closure, and the closure struct itself. Those variables are address-taken. If they are actually live in the defer closure, stack tracing will find them. The non-address-taken variables are not accessible, so we can treat them dead. So, we can just let stack tracing take care of it, without adjusting the PC?

I don't think stack tracing will solve this. x points to heap-allocated memory. x itself doesn't have its address taken, so it is tracked using the old rules. It will certainly be collected at the GC at line 29, and be live again at the the point of the defer.
Or are you suggesting that you no longer have to walk an implicit panic back to the last defer? It may work to just use all the defer closure pointers as roots and use stack tracing to find all the live variables at that point.
We do pass some variables by value instead of reference into closures. Not sure if that would matter or not...
You'd also have to treat output arguments as live, in case of a recover.

Or are you suggesting that you no longer have to walk an implicit panic back to the last defer?

Yes, this is what I was suggesting. We can treat all the non-address-taken variables dead (except the return values). So x in the example will not be live again. And we use stack tracing to find address-taken live variables.

We do pass some variables by value instead of reference into closures. Not sure if that would matter or not...

If I understand correctly, for capture-by-value variables there is a copy of the value in the closure struct. So we don't need the original variable from the dead frame.

Looking at this a bit more, this should work. One complication is that there are locals that are live after a panic: the PAUTOHEAP variables that point to return values that escape. The code that copies these values back into the return slots on the stack run after the defers (after deferreturn), so if the defer recovers those variables are needed.

I think the right answer is to move the pc to the deferreturn call. That should have precisely the bitmap we need (args are dead, return values are live, except the ones which moved to the heap, in which case their PAUTOHEAP variables are live instead).

I think the right answer is to move the pc to the deferreturn call.

I haven't checked, but doesn't this also include variables captured in deferred closures? If so, then if we panicked before all of the defers in the function were pushed, the liveness map at deferretrun could include variables that aren't initialized yet. We could combine this with stack tracing and perhaps stop marking those as live at the deferreturn.

With stack tracing, we won't be including variables captured in deferred closures in the live map, because those are all captured by reference. Those variables will be stack objects and be tracked by pointer, so they only need to be initialized before their address is put in a closure.

Sounds good.

Change https://golang.org/cl/134637 mentions this issue: runtime: on a signal, set traceback address to a deferreturn call

Change https://golang.org/cl/139898 mentions this issue: cmd/link: fix deferreturn location on wasm

Change https://golang.org/cl/190098 mentions this issue: ssa: prototype for open-coded defers (using funcdata)