You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The net/http.conn.serve method is equipped to handle a special case for when panic is called with http.ErrAbortHandler by downstream http.Handler implementations where it silently recovers and prevents the program from crashing.
When chaining http.Handler implementations, if an http.Handler uses golang.org/x/sync/singleflight.Group, and an http.Handler downstream of that panics with http.ErrAbortHandler, the singleflight package recovers from the panic first, wraps the panic value in its own private error type, and re-panics with its private type. When the new panic gets to net/http.conn.serve, a direct comparison is made to see if err != ErrAbortHandler. Since technically err is not ErrAbortHandler, just another error type that wraps ErrAbortHandler, net/http.conn.serve does not handle the special case and allows the program to crash.
Example where net/http.conn.serve handles the panic and the program does not crash:
When using golang.org/x/sync/singleflight.Group in a chain of http.Handler implementations where a panic(http.ErrAbortHandler is called downstream, net/http.conn.serve is able to unwrap errors to determine if the error is actually http.ErrAbortHandler and handle the panic without allowing the program to crash.
What did you see instead?
The program crashes with the message panic: net/http: abort Handler.
The text was updated successfully, but these errors were encountered:
ewohltman
changed the title
affected/package: x/sync
affected/package: x/sync: Program crash when handling panic with wrapped http.ErrAbortHandlerSep 7, 2023
Currently when singleflight recovers from a panic, it wraps it with the private
error type panicError. This change adds an `Unwrap` method to panicError to
allow wrapped errors to be returned.
Updates golang/go#62511
Change-Id: Ia510ad7d5881207ef71f9eb89c1766835af19b6b
Reviewed-on: https://go-review.googlesource.com/c/sync/+/526171
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
The
net/http.conn.serve
method is equipped to handle a special case for when panic is called withhttp.ErrAbortHandler
by downstreamhttp.Handler
implementations where it silently recovers and prevents the program from crashing.When chaining
http.Handler
implementations, if anhttp.Handler
usesgolang.org/x/sync/singleflight.Group
, and anhttp.Handler
downstream of that panics withhttp.ErrAbortHandler
, thesingleflight
package recovers from the panic first, wraps the panic value in its own private error type, and re-panics with its private type. When the new panic gets tonet/http.conn.serve
, a direct comparison is made to see iferr != ErrAbortHandler
. Since technicallyerr
is notErrAbortHandler
, just another error type that wrapsErrAbortHandler
,net/http.conn.serve
does not handle the special case and allows the program to crash.Example where
net/http.conn.serve
handles the panic and the program does not crash:Example using
golang.org/x/sync/singleflight.Group
wherenet/http.conn.serve
does not handle the panic and the program crashes:What did you expect to see?
When using
golang.org/x/sync/singleflight.Group
in a chain ofhttp.Handler
implementations where apanic(http.ErrAbortHandler
is called downstream,net/http.conn.serve
is able to unwrap errors to determine if the error is actuallyhttp.ErrAbortHandler
and handle the panic without allowing the program to crash.What did you see instead?
The program crashes with the message
panic: net/http: abort Handler
.This issue is related to #62510
The text was updated successfully, but these errors were encountered: