runtime: Encountering strange build stack trace when running go build #16627

zg · 2016-08-06T23:52:28Z

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?
Go version go1.6.3 darwin/amd64
What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/zg/work"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.6.3/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.6.3/libexec/pkg/tool/darwin_amd64"
GO15VENDOREXPERIMENT="1"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"

What did you do?
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.

I tried to run go build gitHub.com/sn/service/router and a huge stack trace spit out. After running the command again, it was successful without any issues.

What did you expect to see?
I expected to see the build succeed without any issues on the internals of Go itself.
What did you see instead?
I saw a stack trace that was unrecognizable.

Is there some kind of caching mechanism involved that has to be cleared? When I run go clean and then try doing go build again, things build fine.

Here is the stack trace:

$ go clean && go test github.com/sn/service/router | tee out
# testmain
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x14233b9aa4e2 pc=0xf47b]

runtime stack:
runtime.throw(0x2c4920, 0x2a)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/panic.go:547 +0x90
runtime.sigpanic()
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/sigpanic_unix.go:12 +0x5a
runtime.unlock(0x3a70a0)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/lock_sema.go:107 +0x14b
runtime.(*mheap).alloc_m(0x3a70a0, 0x1, 0x40000000012, 0x71fff0)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/mheap.go:492 +0x314
runtime.(*mheap).alloc.func1()
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/mheap.go:502 +0x41
runtime.systemstack(0xc820039e58)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/asm_amd64.s:307 +0xab
runtime.(*mheap).alloc(0x3a70a0, 0x1, 0x10000000012, 0xf11f)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/mheap.go:503 +0x63
runtime.(*mcentral).grow(0x3a8b50, 0x0)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/mcentral.go:209 +0x93
runtime.(*mcentral).cacheSpan(0x3a8b50, 0x71fff0)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/mcentral.go:89 +0x47d
runtime.(*mcache).refill(0x402000, 0xc800000012, 0x71fff0)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/mcache.go:119 +0xcc
runtime.mallocgc.func2()
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/malloc.go:642 +0x2b
runtime.systemstack(0xc82001d500)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/asm_amd64.s:291 +0x79
runtime.mstart()
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/proc.go:1051

goroutine 1 [running]:
runtime.systemstack_switch()
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/asm_amd64.s:245 fp=0xc82003e9d0 sp=0xc82003e9c8
runtime.mallocgc(0x120, 0x25c4c0, 0xc800000000, 0xc820072240)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/malloc.go:643 +0x869 fp=0xc82003eaa8 sp=0xc82003e9d0
runtime.newarray(0x25c4c0, 0x6, 0x152a68)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/malloc.go:798 +0xc9 fp=0xc82003eae8 sp=0xc82003eaa8
runtime.makeslice(0x1e67a0, 0x6, 0x6, 0x0, 0x0, 0x0)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/slice.go:32 +0x165 fp=0xc82003eb38 sp=0xc82003eae8
cmd/link/internal/ld.readsym(0xc820072240, 0xc82379db00, 0xc821925fe0, 0x7, 0xc8237a4c80, 0x45)
        /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/ld/objfile.go:239 +0xba6 fp=0xc82003ef80 sp=0xc82003eb38
cmd/link/internal/ld.ldobjfile(0xc820072240, 0xc82379db00, 0xc821925fe0, 0x7, 0x8e007, 0xc8237a4c80, 0x45)
        /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/ld/objfile.go:147 +0xa62 fp=0xc82003f190 sp=0xc82003ef80
cmd/link/internal/ld.ldobj(0xc82379db00, 0xc821925fe0, 0x7, 0x8e030, 0xc8237a4c80, 0x45, 0xc821919ac0, 0x3d, 0x1, 0x0)
        /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/ld/lib.go:1351 +0x1569 fp=0xc82003f400 sp=0xc82003f190
cmd/link/internal/ld.objfile(0xc820abca10)
        /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/ld/lib.go:847 +0x10d9 fp=0xc82003f710 sp=0xc82003f400
cmd/link/internal/ld.loadlib()
        /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/ld/lib.go:513 +0x5ce fp=0xc82003f9f0 sp=0xc82003f710
cmd/link/internal/ld.Ldmain()
        /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/ld/pobj.go:214 +0x1cd3 fp=0xc82003fe70 sp=0xc82003f9f0
cmd/link/internal/amd64.Main()
        /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/amd64/obj.go:44 +0x19 fp=0xc82003fe78 sp=0xc82003fe70
main.main()
        /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/main.go:27 +0x36f fp=0xc82003ff50 sp=0xc82003fe78
runtime.main()
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/proc.go:188 +0x2b0 fp=0xc82003ffa0 sp=0xc82003ff50
runtime.goexit()
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc82003ffa8 sp=0xc82003ffa0
FAIL    github.com/sn/service/router [build failed]

The text was updated successfully, but these errors were encountered:

davecheney · 2016-08-06T23:57:58Z

Can you please post the full output from the first failure.

On Sun, Aug 7, 2016 at 9:52 AM, Zack Zatkin-Gold [email protected]
wrote:

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?
Go version go1.6.3 darwin/amd64
2.

What operating system and processor architecture are you using (go env
)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/zg/work"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.6.3/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.6.3/libexec/pkg/tool/darwin_amd64"
GO15VENDOREXPERIMENT="1"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics
-Qunused-arguments -fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"
3.

What did you do?
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.

I tried to run go build gitHub.com/sn/service/helpers and a huge stack
trace spit out. After running the command again, it was successful without
any issues.

What did you expect to see?
I expected to see the build succeed without any issues on the
internals of Go itself.
2.

What did you see instead?
I saw a stack trace that was unrecognizable.

Is there some kind of caching mechanism involved that has to be cleared?
When I run go clean and then try doing go build again, things build fine.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#16627, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAcA6B3Z6ytFG_ka744Ftj21GTsQwLEks5qdR49gaJpZM4JeZD-
.

zg · 2016-08-07T00:00:36Z

Yes, I've attached it at the bottom. Not sure what happened to my clipboard, but it's there now.

davecheney · 2016-08-07T00:02:39Z

Looks like your test program is crashing, you can confirm this with

% go test -c
% ./router.test

This is most likely due to a data race, which can be verified with

% go test -race

or

% go test -c -race
% ./router.test

zg · 2016-08-07T00:13:35Z

How does adding the -race flag verify that there is a race? I'm just seeing the same error again.

$ go test -c -race                                                                                                                                                                                          [3/171]
# testmain
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x15820bc54210 pc=0xf47b]

runtime stack:
runtime.throw(0x2c4920, 0x2a)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/panic.go:547 +0x90
runtime.sigpanic()
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/sigpanic_unix.go:12 +0x5a
runtime.unlock(0x3a70a0)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/lock_sema.go:107 +0x14b
runtime.(*mheap).alloc_m(0x3a70a0, 0x1, 0x1a, 0x778798)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/mheap.go:492 +0x314
runtime.(*mheap).alloc.func1()
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/mheap.go:502 +0x41
runtime.systemstack(0xc82044de58)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/asm_amd64.s:307 +0xab
runtime.(*mheap).alloc(0x3a70a0, 0x1, 0x1000000001a, 0xf11f)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/mheap.go:503 +0x63
runtime.(*mcentral).grow(0x3a8ed0, 0x0)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/mcentral.go:209 +0x93
runtime.(*mcentral).cacheSpan(0x3a8ed0, 0x769ee8)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/mcentral.go:89 +0x47d
runtime.(*mcache).refill(0x402e10, 0x1a, 0x769ee8)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/mcache.go:119 +0xcc
runtime.mallocgc.func2()
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/malloc.go:642 +0x2b
runtime.systemstack(0xc820020000)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/asm_amd64.s:291 +0x79
runtime.mstart()
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/proc.go:1051

goroutine 1 [running]:
runtime.systemstack_switch()
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/asm_amd64.s:245 fp=0xc82003e9d0 sp=0xc82003e9c8
runtime.mallocgc(0x240, 0x25c4c0, 0xc800000000, 0xc820086240)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/malloc.go:643 +0x869 fp=0xc82003eaa8 sp=0xc82003e9d0
runtime.newarray(0x25c4c0, 0xb, 0x152a68)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/malloc.go:798 +0xc9 fp=0xc82003eae8 sp=0xc82003eaa8
runtime.makeslice(0x1e67a0, 0xb, 0xb, 0x0, 0x0, 0x0)
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/slice.go:32 +0x165 fp=0xc82003eb38 sp=0xc82003eae8
cmd/link/internal/ld.readsym(0xc820086240, 0xc8250eb1c0, 0xc821ac9540, 0xd, 0xc8259b5450, 0x50)
        /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/ld/objfile.go:239 +0xba6 fp=0xc82003ef80 sp=0xc82003eb38
cmd/link/internal/ld.ldobjfile(0xc820086240, 0xc8250eb1c0, 0xc821ac9540, 0xd, 0xab5f, 0xc8259b5450, 0x50)
        /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/ld/objfile.go:147 +0xa62 fp=0xc82003f190 sp=0xc82003ef80
cmd/link/internal/ld.ldobj(0xc8250eb1c0, 0xc821ac9540, 0xd, 0xab88, 0xc8259b5450, 0x50, 0xc82307ff90, 0x48, 0x1, 0x0)
        /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/ld/lib.go:1351 +0x1569 fp=0xc82003f400 sp=0xc82003f190
cmd/link/internal/ld.objfile(0xc8230571f0)
        /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/ld/lib.go:847 +0x10d9 fp=0xc82003f710 sp=0xc82003f400
cmd/link/internal/ld.loadlib()
        /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/ld/lib.go:513 +0x5ce fp=0xc82003f9f0 sp=0xc82003f710
cmd/link/internal/ld.Ldmain()
        /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/ld/pobj.go:214 +0x1cd3 fp=0xc82003fe70 sp=0xc82003f9f0
cmd/link/internal/amd64.Main()
        /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/amd64/obj.go:44 +0x19 fp=0xc82003fe78 sp=0xc82003fe70
main.main()
        /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/main.go:27 +0x36f fp=0xc82003ff50 sp=0xc82003fe78
runtime.main()
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/proc.go:188 +0x2b0 fp=0xc82003ffa0 sp=0xc82003ff50
runtime.goexit()
        /usr/local/Cellar/go/1.6.3/libexec/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc82003ffa8 sp=0xc82003ffa0

bradfitz · 2016-08-07T00:30:47Z

This isn't a failure in go build as the title suggests. I agree with Dave that this is probably a test failure due to a race. Closing until there's something we can do.

bradfitz · 2016-08-07T00:31:54Z

Oh this is in the linker. Just read the stack.

bradfitz · 2016-08-07T00:32:17Z

Can you try Go 1.7?

davecheney · 2016-08-07T00:35:10Z

Did you recently upgraded to the macos Sierra beta?

On Sun, 7 Aug 2016, 10:32 Brad Fitzpatrick [email protected] wrote:

Can you try Go 1.7?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#16627 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA8UQKKz88yB9t2-l4oYzHk7Qs8Fqks5qdSeSgaJpZM4JeZD-
.

zg · 2016-08-07T00:39:46Z

@bradfitz: No problem - it is Saturday. 😄 I upgraded to Go 1.7rc5 using brew upgrade go --devel and the problem doesn't arise.

@davecheney: Yep, I'm on macOS Sierra (10.12 Beta).

davecheney · 2016-08-07T00:43:51Z

Your Brew instance is 1.6.3, I think that doesn't have the fix.

I recommend switching to the official release from golang.org.

On Sun, 7 Aug 2016, 10:39 Zack Zatkin-Gold [email protected] wrote:

@bradfitz https://github.com/bradfitz: No problem - it is Saturday. 😄
I upgraded to Go 1.7rc5 using brew upgrade go --devel and the problem
doesn't arise.

@davecheney https://github.com/davecheney: Yep, I'm on macOS Sierra
(10.12 Beta).

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#16627 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA1wiPRThQXnXcPHRZkE9eWMrVN9vks5qdSlVgaJpZM4JeZD-
.

zg · 2016-08-07T00:46:02Z

Which commit on golang/go has the fix?

davecheney · 2016-08-07T00:52:11Z

It's in 1.7rc5, it's not been backported to other branches yet sorry.

On Sun, 7 Aug 2016, 10:46 Zack Zatkin-Gold [email protected] wrote:

Which commit on golang/go has the fix?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#16627 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA3k4BDCjf8JeYtgwUVJwusRCY_Baks5qdSrNgaJpZM4JeZD-
.

zg · 2016-08-07T00:59:35Z

If this was fixed in Go 1.7rc5, then I suppose the issue can be closed.

bradfitz · 2016-08-07T01:14:03Z

Dup of #16352 / #16570

bradfitz closed this as completed Aug 7, 2016

bradfitz reopened this Aug 7, 2016

bradfitz closed this as completed Aug 7, 2016

mikioh changed the title ~~Encountering strange build stack trace when running go build~~ runtime: Encountering strange build stack trace when running go build Oct 13, 2016

mikioh added the OS-Darwin label Oct 13, 2016

robx mentioned this issue Jul 7, 2017

go_1_6: Fix darwin (sierra) compile, backport systime syscall fix NixOS/nixpkgs#27230

Merged

8 tasks

golang locked and limited conversation to collaborators Oct 13, 2017

gopherbot added the FrozenDueToAge label Oct 13, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

runtime: Encountering strange build stack trace when running go build #16627

runtime: Encountering strange build stack trace when running go build #16627

zg commented Aug 6, 2016 •

edited

Loading

davecheney commented Aug 6, 2016

zg commented Aug 7, 2016

davecheney commented Aug 7, 2016

zg commented Aug 7, 2016

bradfitz commented Aug 7, 2016

bradfitz commented Aug 7, 2016

bradfitz commented Aug 7, 2016

davecheney commented Aug 7, 2016

zg commented Aug 7, 2016

davecheney commented Aug 7, 2016

zg commented Aug 7, 2016

davecheney commented Aug 7, 2016

zg commented Aug 7, 2016

bradfitz commented Aug 7, 2016

runtime: Encountering strange build stack trace when running go build #16627

runtime: Encountering strange build stack trace when running go build #16627

Comments

zg commented Aug 6, 2016 • edited Loading

davecheney commented Aug 6, 2016

zg commented Aug 7, 2016

davecheney commented Aug 7, 2016

zg commented Aug 7, 2016

bradfitz commented Aug 7, 2016

bradfitz commented Aug 7, 2016

bradfitz commented Aug 7, 2016

davecheney commented Aug 7, 2016

zg commented Aug 7, 2016

davecheney commented Aug 7, 2016

zg commented Aug 7, 2016

davecheney commented Aug 7, 2016

zg commented Aug 7, 2016

bradfitz commented Aug 7, 2016

zg commented Aug 6, 2016 •

edited

Loading