Skip to content
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

Jump to bottom

net: OpError(nil).Unwrap() crashes, while .Error() doesn't #36368

Closed
rski opened this issue Jan 2, 2020 · 5 comments
Closed

net: OpError(nil).Unwrap() crashes, while .Error() doesn't #36368

rski opened this issue Jan 2, 2020 · 5 comments
Labels
FrozenDueToAge
Milestone
Go1.15

Comments

@rski
Copy link

rski commented Jan 2, 2020

What version of Go are you using (go version)?

go version
go version devel +ffbc02761a Thu Jan 2 21:41:13 2020 +0000 linux/amd64
and
$ go version
go version go1.13.5 linux/amd64

Does this issue reproduce with the latest release?

yes, with go1.13.5

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/rski/.cache/go-build"
GOENV="/home/rski/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/rski/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/nix/store/sz7mgf91bxd3xpxgqjzgr2avl9cshlz8-go-1.13.5/share/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/nix/store/sz7mgf91bxd3xpxgqjzgr2avl9cshlz8-go-1.13.5/share/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="/nix/store/47hi526v96skkwgdj7d9c31ccd1xivrx-gcc-wrapper-8.3.0/bin/cc"
CXX="g++"
CGO_ENABLED="0"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build956886521=/tmp/go-build -gno-record-gcc-switches"

What did you do?

As the summary says, this can be verified by code inspection:

func (e *OpError) Unwrap() error { return e.Err }

func (e *OpError) Error() string {
	if e == nil {
		return "<nil>"
	}

and this is the rerpo:

	err := (*net.OpError)(nil)
	err.Error()
	err.Unwrap() // or errors.Unwrap(err), it's just a call to err.Unrwap really

What did you expect to see?

No crash? Unwrap returning nil? I'm not exactly sure what the right behaviour would be here. I'm in favour of just returning nil, since .Error() has set the precedent and a nil is not wrapping anything. Obviously it's not great to have a typed nil floating about. nor would I want to depend on this behaviour, this is more for consistency's sake.

What did you see instead?

go run *.go
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x46c9dd]

goroutine 1 [running]:
net.(*OpError).Unwrap(...)
	/nix/store/sz7mgf91bxd3xpxgqjzgr2avl9cshlz8-go-1.13.5/share/go/src/net/net.go:458
main.main()
	/home/rski/go/src/playground/at-2020-01-02-212034/snippet.go:18 +0x2d
exit status 2
@ianlancetaylor ianlancetaylor changed the title net.OpError(nil).Unrwap() crashes, while .Error() doesn't net: OpError(nil).Unrwap() crashes, while .Error() doesn't Jan 2, 2020
@ianlancetaylor
Copy link
Contributor

CC @jba @neild

@ianlancetaylor ianlancetaylor added this to the Go1.15 milestone Jan 2, 2020
@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 2, 2020
@jba
Copy link
Contributor

jba commented Jan 2, 2020

In my opinion, Unwrap is doing the right thing, and Error's behavior is a mistake. So I don't think we should "fix" Unwrap for consistency.

Both the unexported error type of the errors package, and the one in fmt used for %w, will panic on nil.

@smasher164 smasher164 changed the title net: OpError(nil).Unrwap() crashes, while .Error() doesn't net: OpError(nil).Unwrap() crashes, while .Error() doesn't Jan 3, 2020
@odeke-em
Copy link
Member

Thank you for filing this bug @rski! @jba, what would your recommendation to move forward be? Should we close this issue as working as intended? It is currently milestoned for Go1.15.

@jba
Copy link
Contributor

jba commented May 18, 2020

I would mark it WAI.

@odeke-em odeke-em removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 18, 2020
@odeke-em
Copy link
Member

Awesome, thank you @jba for the resolution. @rski, thank you again for filing this bug, but it is working as intended, please don’t hesitate however to file more or to ask questions at any of these resources https://github.com/golang/go/wiki/Questions.

@golang golang locked and limited conversation to collaborators May 18, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.15
Development

No branches or pull requests
5 participants
@rski @ianlancetaylor @odeke-em @gopherbot @jba