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.

Sign up for GitHub

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

cmd/go: stale binary used during go generate test? #17692

Closed
rsc opened this issue Oct 31, 2016 · 1 comment
Closed

cmd/go: stale binary used during go generate test? #17692

rsc opened this issue Oct 31, 2016 · 1 comment
Labels
FrozenDueToAge
Milestone
Go1.8

Comments

@rsc
Copy link
Contributor

rsc commented Oct 31, 2016

From all.bash on my laptop. I have CLs pending but nothing in runtime, and this crash is before any user code starts. Up to date as of:

$ git log -n1 $(git codereview branchpoint)
commit 590fce48849cc7f81b890d6e9b6120fc6681e19a
Author:     Nigel Tao <nigeltao@golang.org>
AuthorDate: Sat Oct 29 13:23:50 2016 +1100
Commit:     Nigel Tao <nigeltao@golang.org>
CommitDate: Sun Oct 30 22:52:14 2016 +0000

    compress/flate: tighten the BestSpeed max match offset bound.

Failure:

--- FAIL: TestGoGenerateHandlesSimpleCommand (0.07s)
	go_test.go:251: running testgo [generate ./testdata/generate/test1.go]
	go_test.go:270: standard error:
	go_test.go:271: failed MSpanList_Insert 0x1fc000 0x581630a5324e 0x0 0x0
		fatal error: MSpanList_Insert
		
		runtime stack:
		runtime.throw(0x12c080, 0x10)
			/Users/rsc/go/src/runtime/panic.go:530 +0x90 fp=0x7fff5fbfefe0 sp=0x7fff5fbfefc8
		runtime.(*mSpanList).insert(0x1b94c8, 0x1fc000)
			/Users/rsc/go/src/runtime/mheap.go:933 +0x293 fp=0x7fff5fbff010 sp=0x7fff5fbfefe0
		runtime.(*mheap).freeSpanLocked(0x1b8cc0, 0x1fc000, 0x100, 0x0)
			/Users/rsc/go/src/runtime/mheap.go:809 +0x4be fp=0x7fff5fbff078 sp=0x7fff5fbff010
		runtime.(*mheap).grow(0x1b8cc0, 0x8, 0x0)
			/Users/rsc/go/src/runtime/mheap.go:675 +0x2a0 fp=0x7fff5fbff0d0 sp=0x7fff5fbff078
		runtime.(*mheap).allocSpanLocked(0x1b8cc0, 0x1, 0x0)
			/Users/rsc/go/src/runtime/mheap.go:553 +0x4e3 fp=0x7fff5fbff128 sp=0x7fff5fbff0d0
		runtime.(*mheap).alloc_m(0x1b8cc0, 0x1, 0x15, 0x0)
			/Users/rsc/go/src/runtime/mheap.go:437 +0x119 fp=0x7fff5fbff158 sp=0x7fff5fbff128
		runtime.(*mheap).alloc.func1()
			/Users/rsc/go/src/runtime/mheap.go:502 +0x41 fp=0x7fff5fbff188 sp=0x7fff5fbff158
		runtime.systemstack(0x7fff5fbff1a8)
			/Users/rsc/go/src/runtime/asm_amd64.s:307 +0xab fp=0x7fff5fbff190 sp=0x7fff5fbff188
		runtime.(*mheap).alloc(0x1b8cc0, 0x1, 0x10000000015, 0xdfef)
			/Users/rsc/go/src/runtime/mheap.go:503 +0x63 fp=0x7fff5fbff1d8 sp=0x7fff5fbff190
		runtime.(*mcentral).grow(0x1ba8c0, 0x0)
			/Users/rsc/go/src/runtime/mcentral.go:209 +0x93 fp=0x7fff5fbff240 sp=0x7fff5fbff1d8
		runtime.(*mcentral).cacheSpan(0x1ba8c0, 0x1b5918)
			/Users/rsc/go/src/runtime/mcentral.go:89 +0x47d fp=0x7fff5fbff280 sp=0x7fff5fbff240
		runtime.(*mcache).refill(0x1f8000, 0x15, 0x7fff5fbff2e8)
			/Users/rsc/go/src/runtime/mcache.go:119 +0xcc fp=0x7fff5fbff2b8 sp=0x7fff5fbff280
		runtime.mallocgc.func2()
			/Users/rsc/go/src/runtime/malloc.go:638 +0x2b fp=0x7fff5fbff2d8 sp=0x7fff5fbff2b8
		runtime.systemstack(0x7fff5fbff378)
			/Users/rsc/go/src/runtime/asm_amd64.s:307 +0xab fp=0x7fff5fbff2e0 sp=0x7fff5fbff2d8
		runtime.mallocgc(0x180, 0x111c20, 0x0, 0x800000000)
			/Users/rsc/go/src/runtime/malloc.go:639 +0x869 fp=0x7fff5fbff3b8 sp=0x7fff5fbff2e0
		runtime.newobject(0x111c20, 0x1b5b90)
			/Users/rsc/go/src/runtime/malloc.go:777 +0x42 fp=0x7fff5fbff3e0 sp=0x7fff5fbff3b8
		runtime.malg(0x8000, 0x1b5e00)
			/Users/rsc/go/src/runtime/proc.go:2618 +0x27 fp=0x7fff5fbff418 sp=0x7fff5fbff3e0
		runtime.mpreinit(0x1b6140)
			/Users/rsc/go/src/runtime/os1_darwin.go:140 +0x1f fp=0x7fff5fbff430 sp=0x7fff5fbff418
		runtime.mcommoninit(0x1b6140)
			/Users/rsc/go/src/runtime/proc.go:494 +0x105 fp=0x7fff5fbff478 sp=0x7fff5fbff430
		runtime.schedinit()
			/Users/rsc/go/src/runtime/proc.go:434 +0x79 fp=0x7fff5fbff4c0 sp=0x7fff5fbff478
		runtime.rt0_go(0x7fff5fbff4f0, 0x2, 0x7fff5fbff4f0, 0x0, 0x2, 0x7fff5fbff760, 0x7fff5fbff765, 0x0, 0x7fff5fbff76d, 0x7fff5fbff789, ...)
			/Users/rsc/go/src/runtime/asm_amd64.s:138 +0x132 fp=0x7fff5fbff4c8 sp=0x7fff5fbff4c0
		testdata/generate/test1.go:11: running "echo": exit status 2
		
	go_test.go:280: go [generate ./testdata/generate/test1.go] failed unexpectedly: exit status 1

The problem is that none of the line numbers match up with my current sources. This is the kind of failure I saw when working on the Go 1.7 release branch in a different client, before I had all the Sierra fixes patched in. I wonder if somehow there is a bad binary that is not being rebuilt properly during the test.
@rsc rsc added this to the Go1.8 milestone Oct 31, 2016
@rsc
Copy link
Contributor Author

rsc commented Oct 31, 2016

It looks like I managed to run 'go install' in the gopl.io/ch11/echo directory at some point. That binary was stale (pre-Sierra), causing the pre-Sierra-like crash. Deleted ~/bin/echo and all is well.

/cc @adonovan

@rsc rsc closed this as completed Oct 31, 2016
@golang golang locked and limited conversation to collaborators Oct 31, 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.8
Development

No branches or pull requests
2 participants
@rsc @gopherbot