-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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: 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 <
|
For example : |
Do you have permission to write to $GOPATH ? On Tue, Jun 21, 2016 at 8:59 PM, Stanislas SABATIER <
|
yes, I'm root |
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. |
FYI, this bug appeared after I upgraded go from 1.4.2 to 1.6.2. |
How reproducible is this problem? |
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 |
Hello, |
@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. |
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?
|
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. |
Hi,
|
Do you have any clue on this? It looks similar to #15639 but no cgo stuff in github.com/Masterminds/glide. |
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 |
|
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 |
Hi @mikioh, I have not |
@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. |
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 :
|
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? |
Seems likely dup of #15658. |
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. |
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.The text was updated successfully, but these errors were encountered: