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

runtime: name offset out of range #15372

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

runtime: name offset out of range #15372

bradfitz opened this issue Apr 19, 2016 · 7 comments
Labels
FrozenDueToAge
Milestone
Go1.7Maybe

Comments

@bradfitz
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

rsc commented May 17, 2016

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

@rsc rsc closed this as completed May 17, 2016
@minux minux mentioned this issue May 29, 2016
Closed
@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.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.7Maybe
Development

No branches or pull requests
5 participants
@bradfitz @rsc @crawshaw @ianlancetaylor @gopherbot