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: Panic in golang compiler on macOS Sierra Third Public Beta (16A270f) #16585

Closed
n1rvana opened this issue Aug 3, 2016 · 6 comments
Closed

Comments

@n1rvana
Copy link

n1rvana commented Aug 3, 2016

Please answer these questions before submitting your issue. Thanks!

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

Third public beta of macOS Sierra 10.12 (build 16A270f)

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/userid/codex/gopath_m2"
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"
  1. What did you do?

I checked out and tried to install:
https://github.com/n1rvana/go-spammer

This is a trivial app. This issue has appeared with all apps I've tried to compile since installing this beta of the OS.

  1. What did you expect to see?
    Successful build
  2. What did you see instead?
/go-spammer/ (m2) 🌀  go install
# github.com/n1rvana/go-spammer
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x14e5a4567ffe 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, 0x12, 0x45b558)
    /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(0x7fff5fbfee98)
    /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, 0x45b558)
    /usr/local/Cellar/go/1.6.3/libexec/src/runtime/mcentral.go:89 +0x47d
runtime.(*mcache).refill(0x402000, 0x12, 0x45b558)
    /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(0x3a0700)
    /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=0xc82003e878 sp=0xc82003e870
runtime.mallocgc(0x120, 0x276fa0, 0x0, 0x1d7520)
    /usr/local/Cellar/go/1.6.3/libexec/src/runtime/malloc.go:643 +0x869 fp=0xc82003e950 sp=0xc82003e878
runtime.newobject(0x276fa0, 0xc82000e570)
    /usr/local/Cellar/go/1.6.3/libexec/src/runtime/malloc.go:781 +0x42 fp=0xc82003e978 sp=0xc82003e950
cmd/link/internal/ld._lookup(0xc82001e360, 0xc8202f4630, 0x24, 0x0, 0x1, 0x24)
    /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/ld/sym.go:201 +0xf3 fp=0xc82003e9f0 sp=0xc82003e978
cmd/link/internal/ld.Linklookup(0xc82001e360, 0xc8202f4630, 0x24, 0x0, 0xc8202f4630)
    /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/ld/sym.go:208 +0x48 fp=0xc82003ea28 sp=0xc82003e9f0
cmd/link/internal/ld.rdsym(0xc82001e360, 0xc8200ea3c0, 0x27e550, 0x7, 0x0)
    /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/ld/objfile.go:459 +0x232 fp=0xc82003eb38 sp=0xc82003ea28
cmd/link/internal/ld.readsym(0xc82001e360, 0xc8200ea3c0, 0x27e550, 0x7, 0xc820016dc0, 0x45)
    /usr/local/Cellar/go/1.6.3/libexec/src/cmd/link/internal/ld/objfile.go:249 +0xd5b fp=0xc82003ef80 sp=0xc82003eb38
cmd/link/internal/ld.ldobjfile(0xc82001e360, 0xc8200ea3c0, 0x27e550, 0x7, 0x2a1a54, 0xc820016dc0, 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(0xc8200ea3c0, 0x27e550, 0x7, 0x2a1aae, 0xc820016dc0, 0x45, 0xc820014f40, 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(0xc82001a4d0)
    /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
/go-spammer/ (m2) 🌀
@n1rvana
Copy link
Author

n1rvana commented Aug 3, 2016

I realize this is a dupe of: #16570

There has been a commit to the repo (but not clear which branch) that closes that issue.

Would it be possible to refer to a method to produce a working set of go binaries with that patch? Or the right commit?

The method mentioned in that thread seemed to involve two Macs, one to build 1.4, then another to use that 1.4 to build a later version.

@n1rvana
Copy link
Author

n1rvana commented Aug 3, 2016

Found solution is to use Go 1.7rc5 as workaround:
https://golang.org/doc/install?download=go1.7rc5.darwin-amd64.pkg

@n1rvana n1rvana closed this as completed Aug 3, 2016
@johnzeng
Copy link

using 1.6.3 and suffering the same issue.... Is it necessary to upgrade the complier to 1.7 ? I wanna keep using 1.6

@davecheney
Copy link
Contributor

Why do you want to use 1.6, 1.7.1 is better in every single way.

On Fri, Sep 23, 2016 at 6:01 PM, John Zeng notifications@github.com wrote:

using 1.6.3 and suffering the same issue.... Is it necessary to upgrade
the complier to 1.7 ? I wanna keep using 1.6


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#16585 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcAyrZL8Xp8GsIOyHdj4-Ie_4z510Oks5qs4dDgaJpZM4Jb3g_
.

@johnzeng
Copy link

@davecheney Actually it's ok for me to upgrade to 1.7 , but not my production env.... Any way, production is using linux, it's ok so far.

@geoherna
Copy link

Was having the exact same issue and upgrading to 1.7 fixed for me.

@mikioh mikioh changed the title Panic in golang compiler on macOS Sierra Third Public Beta (16A270f) runtime: Panic in golang compiler on macOS Sierra Third Public Beta (16A270f) Oct 13, 2016
@golang golang locked and limited conversation to collaborators Oct 13, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants