Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
runtime: exitsyscall: syscall frame is no longer valid (FreeBSD) #16136
Comments
What is the complete failing command ? On Tue, Jun 21, 2016 at 8:44 PM, Stanislas SABATIER <
|
sapiens-sapide
commented
Jun 21, 2016
For example : |
Do you have permission to write to $GOPATH ? On Tue, Jun 21, 2016 at 8:59 PM, Stanislas SABATIER <
|
sapiens-sapide
commented
Jun 21, 2016
yes, I'm root |
franciscocpg
referenced this issue
in Masterminds/glide
Jun 21, 2016
Open
Build fails in freeBSD #482
ianlancetaylor
changed the title from
go install randomly crash on freeBSD
to
cmd/go: go install randomly crash on freeBSD
Jun 21, 2016
ianlancetaylor
added
the
OS-FreeBSD
label
Jun 21, 2016
ianlancetaylor
added this to the Go1.7Maybe milestone
Jun 21, 2016
This is failing with signal 10, which is The stack trace seems to show that Holding the fork lock suggests this may be related to #15658, another FreeBSD issue that somehow involves the fork/exec code. |
sapiens-sapide
commented
Jun 22, 2016
FYI, this bug appeared after I upgraded go from 1.4.2 to 1.6.2. |
How reproducible is this problem? |
mikioh
changed the title from
cmd/go: go install randomly crash on freeBSD
to
cmd/go: go install randomly crash on FreeBSD
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 |
sapiens-sapide
commented
Jun 23, 2016
Hello, |
sapiens-sapide
commented
Jun 23, 2016
@ianlancetaylor : to reproduce, just try to |
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. |
mikioh
removed
the
OS-FreeBSD
label
Jun 23, 2016
sapiens-sapide
commented
Jun 23, 2016
I put « randomly », because the bug is difficult to reproduce. It is related to the
If I retry later, |
I cannot reproduce your issue. Can you try the following procedure and report back the result?
|
sapiens-sapide
commented
Jun 26, 2016
•
Hi,
After a while (five minutes ?) I hit
I can provide you with the core dump file if needed (it's 36M) |
Looks like you didin't.
Why? I believe that no one ensures that it accomplishes within 5 mins. Did you check that there's no remaining processes created by the script when you killed the first run? Did you check that the crashed go command is created by which parent process? Please do not interrupt the shell run unless you are sure what you are doing, and please run the script until crash. Thanks. |
sapiens-sapide
commented
Jun 27, 2016
Hi,
|
mikioh
changed the title from
cmd/go: go install randomly crash on FreeBSD
to
runtime: fatal error: runtime: stack split at bad time in syscall.Wait4
Jun 27, 2016
mikioh
changed the title from
runtime: fatal error: runtime: stack split at bad time in syscall.Wait4
to
runtime: fatal error: runtime: stack split at bad time in exitsyscall
Jun 27, 2016
mikioh
changed the title from
runtime: fatal error: runtime: stack split at bad time in exitsyscall
to
runtime: exitsyscall: syscall frame is no longer valid
Jun 27, 2016
Do you have any clue on this? It looks similar to #15639 but no cgo stuff in github.com/Masterminds/glide. |
sapiens-sapide
commented
Jun 27, 2016
•
FYI, I ran again the
and the output :
@mikioh : may I kill it ? ;-) |
Sure. ;) The script is dumb, you need to kill all spawned processes by hand before the next run. I'm not sure the reason why I cannot reproduce your issue on my FreeBSD VM. Perhaps, it might depend on your circumstances. Can you show us your FreeBSD profile? I think the output of |
sapiens-sapide
commented
Jun 27, 2016
•
|
ianlancetaylor
added
the
OS-FreeBSD
label
Jun 28, 2016
I tried to recreate the problem using gomote, but failed. @sapiens-sapide Can you try to recreate this using Go 1.7beta2, or tip? That should at least give a better error message. The real error message from 1.6 is being hidden by a bug that has been fixed. My best guess at the moment is that something has gone wrong with our support for fork on FreeBSD, but I have no idea what that could be. |
In addition,
This is a sort of random firing, though. Can you try with disabling Intel VT-x support? If your kernel has the kernel state entry |
sapiens-sapide
commented
Jun 30, 2016
•
Hi @mikioh, I have not |
sapiens-sapide
commented
Jun 30, 2016
@ianlancetaylor,
|
Thanks, then, can you try with disabling Intel Hyperthreading support? We see 8 CPUs in dmesg, but E5-1620v2 implements only 4 cores. I guess that you probably need to tweak UEFI or BIOS to turn off Intel HT. |
Thanks for running it on tip. This version of the error just looks like memory corruption. If there is a problem in the Go distribution, I think it must be in the fork support on FreeBSD. @sapiens-sapide The original report says you are running FreeBSD 10.0-RELEASE-p9. @mikioh Which exact FreeBSD version are you trying? Has anybody been able to reproduce this on a second machine? Could there simply be something wrong with the single machine showing the problem? |
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. |
Still don't know what is happening here. Postponing to 1.8. |
ianlancetaylor
modified the milestones:
Go1.8Early,
Go1.7Maybe
Jul 7, 2016
sapiens-sapide
commented
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
referenced this issue
Jul 17, 2016
Closed
runtime: re-enable TestCgoCallbackGC flaky on FreeBSD #16396
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? |
quentinmit
added
the
NeedsInvestigation
label
Sep 30, 2016
Seems likely dup of #15658. |
rsc
modified the milestones:
Go1.8Maybe,
Go1.8Early
Oct 20, 2016
rsc
changed the title from
runtime: exitsyscall: syscall frame is no longer valid
to
runtime: exitsyscall: syscall frame is no longer valid (FreeBSD)
Oct 20, 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. |
sapiens-sapide commentedJun 21, 2016
Please answer these questions before submitting your issue. Thanks!
go version
)?go1.6.2 freebsd/amd64
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"
when I run
go install
for local projects or cloned projects, the installation (randomly !) fails with the following output:If I run the
go build
command on the same package, build is OK.