New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: panic + recover can cancel a call to Goexit #29226

Open
bcmills opened this Issue Dec 13, 2018 · 1 comment

Comments

Projects
None yet
2 participants
@bcmills
Copy link
Member

bcmills commented Dec 13, 2018

The documentation for runtime.Goexit says (emphasis mine):

Goexit terminates the goroutine that calls it. No other goroutine is affected. Goexit runs all deferred calls before terminating the goroutine. Because Goexit is not a panic, any recover calls in those deferred functions will return nil.

However, this is empirically not the case if one of the deferred functions itself triggers a panic: that panic can be recovered, and that recover cancels the termination of the goroutine.

See https://play.golang.org/p/7VrxPDByUNT for a minimal illustration.

Found while investigating #29207.

CC @aclements @randall77

@bcmills bcmills added this to the Go1.13 milestone Dec 13, 2018

@randall77

This comment has been minimized.

Copy link
Contributor

randall77 commented Dec 28, 2018

Panics within panics hurt my brain.

I don't think this would be too hard to fix. We just need another bit in the goroutine to record the "in Goexit" state.

There's a comment in the runtime (from 2014):

		// If defer was started by earlier panic or Goexit (and, since we're back here, that triggered a new panic),
		// take defer off list. The earlier panic or Goexit will not continue running.

So it looks like the current behavior is at least somewhat intentional.
@rsc, who wrote that comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment