Repository navigation
runtime: exitsyscall: syscall frame is no longer valid (FreeBSD) #16136
Description
Please answer these questions before submitting your issue. Thanks!
- What version of Go are you using (
go version)?
go1.6.2 freebsd/amd64 - What operating system and processor architecture are you using (
go env)?
freebsd 10.0-RELEASE-p9
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="freebsd"
GOOS="freebsd"
GOPATH="/usr/local/goland/"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/freebsd_amd64"
GO15VENDOREXPERIMENT="1"
CC="cc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="clang++"
CGO_ENABLED="1" - What did you do?
when I rungo installfor local projects or cloned projects, the installation (randomly !) fails with the following output:
unexpected fault address 0xc82048d500
fatal error: fault
[signal 0xa code=0xc addr=0xc82048d500 pc=0xc82048d500]
goroutine 7 [running]:
runtime.throw(0x9e4730, 0x5)
/usr/local/go/src/runtime/panic.go:547 +0x90 fp=0xc820022580 sp=0xc820022568
runtime.sigpanic()
/usr/local/go/src/runtime/sigpanic_unix.go:21 +0x1e4 fp=0xc8200225d0 sp=0xc820022580
created by main.(*builder).do
/usr/local/go/src/cmd/go/build.go:1320 +0x39e
goroutine 1 [semacquire]:
sync.runtime_Semacquire(0xc8201f3a7c)
/usr/local/go/src/runtime/sema.go:47 +0x26
sync.(*WaitGroup).Wait(0xc8201f3a70)
/usr/local/go/src/sync/waitgroup.go:127 +0xb4
main.(*builder).do(0xc82031d0a0, 0xc8203e3110)
/usr/local/go/src/cmd/go/build.go:1323 +0x3c6
main.runInstall(0xc87c60, 0xc8200701d0, 0x1, 0x1)
/usr/local/go/src/cmd/go/build.go:634 +0x4e5
main.main()
/usr/local/go/src/cmd/go/main.go:181 +0x783
goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1998 +0x1
goroutine 20 [syscall]:
os/signal.signal_recv(0x0)
/usr/local/go/src/runtime/sigqueue.go:116 +0x132
os/signal.loop()
/usr/local/go/src/os/signal/signal_unix.go:22 +0x18
created by os/signal.init.1
/usr/local/go/src/os/signal/signal_unix.go:28 +0x37
goroutine 3 [semacquire]:
sync.runtime_Semacquire(0xcac1ec)
/usr/local/go/src/runtime/sema.go:47 +0x26
sync.(*RWMutex).RLock(0xcac1e0)
/usr/local/go/src/sync/rwmutex.go:37 +0x58
os.Pipe(0x9, 0x0, 0x0, 0x0)
/usr/local/go/src/os/pipe_bsd.go:17 +0x4f
os/exec.(*Cmd).writerDescriptor(0xc820163680, 0x800dbc800, 0xc820198fc0, 0x0, 0x0, 0x0)
/usr/local/go/src/os/exec/exec.go:228 +0x27a
os/exec.(*Cmd).stdout(0xc820163680, 0x0, 0x0, 0x0)
/usr/local/go/src/os/exec/exec.go:204 +0x4c
os/exec.(*Cmd).Start(0xc820163680, 0x0, 0x0)
/usr/local/go/src/os/exec/exec.go:316 +0x2f4
os/exec.(*Cmd).Run(0xc820163680, 0x0, 0x0)
/usr/local/go/src/os/exec/exec.go:259 +0x2d
main.(*builder).runOut(0xc82031d0a0, 0xc8201c94a0, 0x54, 0xc8202b44c0, 0x3e, 0x0, 0x0, 0x0, 0xc8204211e0, 0x14, ...)
/usr/local/go/src/cmd/go/build.go:2049 +0x364
main.gcToolchain.gc(0xc82031d0a0, 0xc82039bc00, 0xc82006dc80, 0x57, 0xc82006dbc0, 0x5b, 0x0, 0xc82045a6e0, 0x2, 0x2, ...)
/usr/local/go/src/cmd/go/build.go:2310 +0x1261
main.(*gcToolchain).gc(0xcac038, 0xc82031d0a0, 0xc82039bc00, 0xc82006dc80, 0x57, 0xc82006dbc0, 0x5b, 0x0, 0xc82045a6e0, 0x2, ...)
<autogenerated>:3 +0x18e
main.(*builder).build(0xc82031d0a0, 0xc82015bee0, 0x0, 0x0)
/usr/local/go/src/cmd/go/build.go:1484 +0x224c
main.(*builder).do.func1(0xc82015bee0)
/usr/local/go/src/cmd/go/build.go:1257 +0x3b2
main.(*builder).do.func2(0xc8201f3a70, 0xc82031d0a0, 0xc82045a560)
/usr/local/go/src/cmd/go/build.go:1314 +0x156
created by main.(*builder).do
/usr/local/go/src/cmd/go/build.go:1320 +0x39e
goroutine 4 [semacquire]:
sync.runtime_Semacquire(0xc82031d0e4)
/usr/local/go/src/runtime/sema.go:47 +0x26
sync.(*Mutex).Lock(0xc82031d0e0)
/usr/local/go/src/sync/mutex.go:83 +0x1c4
main.(*builder).do.func2(0xc8201f3a70, 0xc82031d0a0, 0xc82045a560)
/usr/local/go/src/cmd/go/build.go:1311 +0xfc
created by main.(*builder).do
/usr/local/go/src/cmd/go/build.go:1320 +0x39e
goroutine 5 [semacquire]:
sync.runtime_Semacquire(0xc82031d0e4)
/usr/local/go/src/runtime/sema.go:47 +0x26
sync.(*Mutex).Lock(0xc82031d0e0)
/usr/local/go/src/sync/mutex.go:83 +0x1c4
main.(*builder).do.func2(0xc8201f3a70, 0xc82031d0a0, 0xc82045a560)
/usr/local/go/src/cmd/go/build.go:1311 +0xfc
created by main.(*builder).do
/usr/local/go/src/cmd/go/build.go:1320 +0x39e
goroutine 6 [select]:
main.(*builder).do.func2(0xc8201f3a70, 0xc82031d0a0, 0xc82045a560)
/usr/local/go/src/cmd/go/build.go:1304 +0x1cf
created by main.(*builder).do
/usr/local/go/src/cmd/go/build.go:1320 +0x39e
goroutine 8 [semacquire]:
runtime.gopark(0x0, 0xc820022f58, 0xc82006c660, 0xc82006c660, 0xc82006c660, 0x4dcfa0)
/usr/local/go/src/runtime/proc.go:262 +0x163
created by main.(*builder).do
/usr/local/go/src/cmd/go/build.go:1320 +0x39e
goroutine 9 [semacquire]:
sync.runtime_Semacquire(0xc82031d0e4)
/usr/local/go/src/runtime/sema.go:47 +0x26
sync.(*Mutex).Lock(0xc82031d0e0)
/usr/local/go/src/sync/mutex.go:83 +0x1c4
main.(*builder).do.func2(0xc8201f3a70, 0xc82031d0a0, 0xc82045a560)
/usr/local/go/src/cmd/go/build.go:1311 +0xfc
created by main.(*builder).do
/usr/local/go/src/cmd/go/build.go:1320 +0x39e
goroutine 10 [running]:
goroutine running on other thread; stack unavailable
created by main.(*builder).do
/usr/local/go/src/cmd/go/build.go:1320 +0x39e
If I run the go build command on the same package, build is OK.
Activity
davecheney commentedon Jun 21, 2016
What is the complete failing command ?
On Tue, Jun 21, 2016 at 8:44 PM, Stanislas SABATIER <
notifications@github.com> wrote:
sapiens-sapide commentedon Jun 21, 2016
For example :
go install github.com/Masterminds/glidecrashes butgo build github.com/Masterminds/glideis OK.davecheney commentedon Jun 21, 2016
Do you have permission to write to $GOPATH ?
On Tue, Jun 21, 2016 at 8:59 PM, Stanislas SABATIER <
notifications@github.com> wrote:
sapiens-sapide commentedon Jun 21, 2016
yes, I'm root
[-]go install randomly crash on freeBSD[/-][+]cmd/go: go install randomly crash on freeBSD[/+]ianlancetaylor commentedon Jun 21, 2016
This is failing with signal 10, which is
SIGBUS. The address and the PC value are the same, suggesting that the program has branched to non-executable code. The address is in the heap, so it is naturally non-executable. The question is why and how the program branched to that location. This can only be memory corruption of some sort.The stack trace seems to show that
syscall.ForkLockis held at the point of the crash, but I don't see any goroutine actually doing a fork/exec. I see a goroutine starting a fork/exec.Holding the fork lock suggests this may be related to #15658, another FreeBSD issue that somehow involves the fork/exec code.
sapiens-sapide commentedon Jun 22, 2016
FYI, this bug appeared after I upgraded go from 1.4.2 to 1.6.2.
ianlancetaylor commentedon Jun 22, 2016
How reproducible is this problem?
[-]cmd/go: go install randomly crash on freeBSD[/-][+]cmd/go: go install randomly crash on FreeBSD[/+]mikioh commentedon Jun 23, 2016
I guess that you are probably trying to make stuff by using both go1.4 and go1.6 packages. In general, it leads to messed up executable images. What happens when you run
sudo pkg delete -y go && sudo pkg install -y go && rm -rf $GOPATH/pkg && go install -x -v github.com/Masterminds/glide?sapiens-sapide commentedon Jun 23, 2016
Hello,
go install -x -v github.com/Masterminds/glideworked after removing and reinstalling go ! \o/BUT, I tried to do the same with two other popular softwares
github.com/coreos/etcdandgithub.com/gogits/gogs=> they both failed to install with the same error output…sapiens-sapide commentedon Jun 23, 2016
@ianlancetaylor : to reproduce, just try to
go getandgo installsoftware from popular repositories (gogs, etcd, beego…). With go 1.6.2 on a freeBSD 10.0-RELEASE-p9, many fail to do the job…mikioh commentedon Jun 23, 2016
@sapiens-sapide,
Unfortunately it's pretty hard to read out useful information between above lines. If you believe that your issue is a bug on language spec. or standard library/commands, please describe the following:
In your case, the recipe must be a complete history of commands. Thanks.
20 remaining items
mikioh commentedon Jul 1, 2016
From 10.0 through 10.3 VM on several x64/amd64 processors (up to 2 cores) w/ 1GiB memory. I always disable any processor's virtualization technology such as VT-x/hyperthreading to avoid facing a few critical kernel bugs fixed in the latest 10.3.
ianlancetaylor commentedon Jul 7, 2016
Still don't know what is happening here. Postponing to 1.8.
sapiens-sapide commentedon Jul 11, 2016
for information — if it may help to find out what's happening — here is another crash log from caddy on the same machine. Caddy server works fine for 24 to 48 hours, until it crashes with the following output :
ianlancetaylor commentedon Jul 20, 2016
I just ran g.sh for 30 minutes with no problems on a FreeBSD 10.1 system running on GCE. How long does it usually take you to see a problem?
rsc commentedon Oct 20, 2016
Seems likely dup of #15658.
Also seems likely to be a kernel problem.
[-]runtime: exitsyscall: syscall frame is no longer valid[/-][+]runtime: exitsyscall: syscall frame is no longer valid (FreeBSD)[/+]rsc commentedon Nov 2, 2016
Cannot reproduce, and reporting a problem in a possibly very different code base (Go from three months ago). Closing. Please file a new issue if new crashes arise.