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: name offset out of range #15372

Closed
bradfitz opened this issue Apr 19, 2016 · 7 comments

Comments

Projects
None yet
5 participants
@bradfitz
Copy link
Member

commented Apr 19, 2016

I've increasingly been getting this crash when running tests:

$ go test -v
runtime: nameOff 0x555b70 out of range 0x555000 - 0x5dffc5
fatal error: runtime: name offset out of range

runtime stack:
runtime.throw(0x5b6ba8, 0x21)
        /home/bradfitz/go/src/runtime/panic.go:566 +0x8b fp=0x7ffd630336b8 sp=0x7ffd630336a0
runtime.resolveNameOff(0x57af80, 0x555b70, 0x6984c0)
        /home/bradfitz/go/src/runtime/type.go:179 +0x324 fp=0x7ffd63033718 sp=0x7ffd630336b8
runtime.(*_type).nameOff(0x57af80, 0x555b70, 0x0)
        /home/bradfitz/go/src/runtime/type.go:185 +0x29 fp=0x7ffd63033738 sp=0x7ffd63033718
runtime.additab(0x67b920, 0x570001)
        /home/bradfitz/go/src/runtime/iface.go:103 +0x10f fp=0x7ffd63033810 sp=0x7ffd63033738
runtime.itabsinit()
        /home/bradfitz/go/src/runtime/iface.go:149 +0x72 fp=0x7ffd63033848 sp=0x7ffd63033810
runtime.schedinit()
        /home/bradfitz/go/src/runtime/proc.go:441 +0x83 fp=0x7ffd63033880 sp=0x7ffd63033848
runtime.rt0_go(0x7ffd630338b8, 0x2, 0x7ffd630338b8, 0x0, 0x7fe8d07dbb2a, 0x2, 0x7ffd63034317, 0x7ffd6303434a, 0x0, 0x7ffd63034357, ...)
        /home/bradfitz/go/src/runtime/asm_amd64.s:145 +0x14f fp=0x7ffd63033888 sp=0x7ffd63033880
exit status 2
FAIL    crypto/x509     0.004s

I've come to learn it means I need to run make.bash again, but surely there's a better error message that could tell me that.

@crawshaw?

@bradfitz bradfitz added this to the Go1.7 milestone Apr 19, 2016

@crawshaw

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2016

What does increasingly mean?

It looks like your compiler and stdlib are out of sync across one of my CLs that changes the type data layout. If that's all this is, I expect it to stop when I stop making type data changes in a couple of weeks. (There are more I could make next cycle, but I'd have to find a pressing need for the changes.) If it's something more than that, I can take a look if you can give me instructions on how to reproduce this.

If you want a general-purpose solution we could have the compiler check that it is in sync with its GOROOT. But that would mess with my personal workflow where I let them drift deliberately to experiment quickly, so I'm not keen on that.

Unassigning myself, because I don't think there's anything specific to my work to fix this (except stopping), and I can't see a general fix.

@crawshaw crawshaw removed their assignment Apr 19, 2016

@bradfitz

This comment has been minimized.

Copy link
Member Author

commented Apr 19, 2016

Sorry, by "increasingly" I mean "many times in the past week".

It's just a useless failure message. I don't have suggestions for a fix.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2016

The compiler and the runtime package are closely tied together, in the sense that there are CL ranges (C1,C2) where if the compiler is in that range the runtime must also be in that range. The go tool rebuilds the runtime when the source code changes, but it does not rebuild the compiler. So it's easy for the runtime to be in one range and the compiler in another. Usually this causes a failure to link, which is an obvious failure mode. @crawshaw 's recent changes cause a failure to run.

I can imagine a couple of ways to fix this, but they all have costs. The problem only affects very active developers. If there is a fairly cheap fix, we should implement it. Otherwise I'm not sure it's worth it.

@bradfitz

This comment has been minimized.

Copy link
Member Author

commented Apr 19, 2016

cmd/go already has logic for computing the buildID of a package.

Could we bake the runtime's buildID into the tools, and then if cmd/go is run and it's not a release build, it could re-compute the runtime's buildID and pass it to the tools via a flag? go tool compile -expect-runtime-build-id=xxxxxxx and then cmd/compile could explode if its baked-in runtime buildid doesn't match?

@bradfitz bradfitz modified the milestones: Go1.7Maybe, Go1.7 Apr 19, 2016

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2016

I think the cost of that approach is that you will have to run make.bash in many cases where you don't currently have to, like whenever the runtime package changes in a way that doesn't matter, which is almost all of the runtime package changes.

@bradfitz

This comment has been minimized.

Copy link
Member Author

commented Apr 19, 2016

Instead of cmd/compile failing immediately, it could just note that it's old & tainted, and then wait to panic or otherwise fail later, and fail with a nicer error message ("compiler out of date"). But if it happens to compile successfully, proceed as normal.

@rsc

This comment has been minimized.

Copy link
Contributor

commented May 17, 2016

I think we have gotten through this. It's unfortunate but not worth fixing by itself.

@rsc rsc closed this May 17, 2016

@golang golang locked and limited conversation to collaborators May 17, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.