runtime: recover calls in loop body of ranging over iterators doesn't take effect

[zigo101]

Go version

go version go1.24.0 linux/amd64

Output of go env in your module/workspace:

.

What did you do?

package main

import "fmt"

func main() {
	defer foo()
	panic(123)
}

func foo() {
	for i := range iter {
		fmt.Println(i, recover()) // 0 <nil>
	}
}

func iter(yield func(int) bool) {
	yield(0)
}

What did you see happen?

0 <nil>
panic: 123

goroutine 1 [running]:
main.main()

What did you expect to see?

0 123

[zigo101]

Some like #71675, but different.

[zigo101]

BTW, I'm not sure whether or not the panic should be caught in the following code. Now it doesn't.

package main

import "fmt"

func main() {
	defer foo()
	panic(123)
}

func foo() {
	for range iter {}
}

func iter(yield func(int) bool) {
	fmt.Println(">", recover()) // > <nil>
	yield(0)
}

[gabyhelp]

Related Issues

• runtime: recover added in range-over-func loop body doesn't stop panic propagation / segfaults printing error #71675
• runtime: confusing panic on parallel calls to yield function #68897
• iter: `iter.Pull` should forward panics and `runtime.Goexit` [freeze exception] #67712 (closed)
• runtime: can't recover #50512 (closed)
• runtime: recover is ineffective in some interface method calls #5406 (closed)
• panic when range-func return nil #69042 (closed)

Related Documentation

• Go Wiki: Rangefunc Experiment > What happens if the loop body panics? Or if the iterator function panics?

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

[dmitshur]

CC @golang/runtime.

[mknyszek]

In triage, we think this is almost certainly the same bug as #71675.

[zigo101]

It looks to me that in #71675, something was done incorrectly.

However, for the current issue, something was forgotten to do.

[cherrymui]

While the symptoms look different, the underlying cause is probably the same -- recover matched to the wrong frame. And the fix is probably the same.

[dr2chase]

This is not a duplicate; the fix for #71675 does not fix this.