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

runtime: nameOff 0x1359ea0 out of range 0xae3000 - 0xead27e #35145

Closed
RO-29 opened this issue Oct 25, 2019 · 3 comments
Closed

runtime: nameOff 0x1359ea0 out of range 0xae3000 - 0xead27e #35145

RO-29 opened this issue Oct 25, 2019 · 3 comments

Comments

@RO-29
Copy link

@RO-29 RO-29 commented Oct 25, 2019

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

$ go version
1.13.3

Does this issue reproduce with the latest release?

yes

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/developers/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
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 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build347085173=/tmp/go-build -gno-record-gcc-switch

What did you do?

Log the error

    var werr interface {
        HTTPServerRequest() *http.Request
    }
    ok := errors.As(myerr, &werr)
    if ok {
        return werr.HTTPServerRequest()
    }
    return nil
}

What did you expect to see?

Don't panic

What did you see instead?

Code was panicking

runtime: nameOff 0x1359ea0 out of range 0xae3000 - 0xead27e
fatal error: runtime: name offset out of range
goroutine 39 [running]:
runtime.throw(0xc9b54b, 0x21)
/usr/local/go/src/runtime/panic.go:774 +0x72 fp=0xc0004c5a10 sp=0xc0004c59e0 pc=0x430f42
runtime.resolveNameOff(0xbb7460, 0x1359ea0, 0xb05eb4)
/usr/local/go/src/runtime/type.go:190 +0x2e7 fp=0xc0004c5a78 sp=0xc0004c5a10 pc=0x457c87
internal/reflectlite.resolveNameOff(0xbb7460, 0x1359ea0, 0xb05eb4)
/usr/local/go/src/runtime/runtime1.go:497 +0x33 fp=0xc0004c5aa0 sp=0xc0004c5a78 pc=0x4413f3
internal/reflectlite.(*rtype).nameOff(...)
/usr/local/go/src/internal/reflectlite/type.go:416
internal/reflectlite.implements(0xba38e0, 0xbb7460, 0x7f2354348b00)
/usr/local/go/src/internal/reflectlite/type.go:749 +0x4fa fp=0xc0004c5bd8 sp=0xc0004c5aa0 pc=0x469ffa
internal/reflectlite.(*rtype).AssignableTo(0xbb7460, 0xe818e0, 0xba38e0, 0x7f2354348b78)
/usr/local/go/src/internal/reflectlite/type.go:680 +0x81 fp=0xc0004c5c00 sp=0xc0004c5bd8 pc=0x469a91
errors.As(0xe66740, 0xc0002e3420, 0xb414e0, 0xc0002c68a0, 0xc0002c6890)
/usr/local/go/src/errors/wrap.go:80 +0x252 fp=0xc0004c5cc0 sp=0xc0004c5c00 pc=0x46d622
@randall77

This comment has been minimized.

Copy link
Contributor

@randall77 randall77 commented Oct 25, 2019

Could you provide a complete program that demonstrates the error?

@pierrre

This comment has been minimized.

Copy link

@pierrre pierrre commented Oct 29, 2019

Hello !
(I'm working at the same company as @RO-29 , so I'm also trying to fix this issue)

Could you provide a complete program that demonstrates the error?

It will be very difficult:

  • it's a closed source application
  • the code size is quite large
  • it happened once on a server, and we can't reproduce the issue anymore

According to the other Github issues that match the search fatal error: runtime: name offset out of range, it seems related to a memory corruption.
We are not using the unsafe package anywhere in our application. (maybe a third party dependencies is doing it 🤷‍♂ )

The code that triggered the error is

    var werr interface {
        HTTPServerRequest() *http.Request
    }
    ok := errors.As(myerr, &werr)
    if ok {
        return werr.HTTPServerRequest()
    }
    return nil

We are trying to find the error in the chain that matches this interface.

Since we're not able to reproduce the error easily, should we close the Github issue ?

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 29, 2019

I agree that this looks like memory corruption. If it happened exactly once and you can't reproduce it, then I don't think we'll be able to make progress. So closing. But please do comment if it happens again. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.