This comment has been minimized.

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.ForkLock is 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.

This comment has been minimized.

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?

This comment has been minimized.

Hello,go install -x -v github.com/Masterminds/glide worked after removing and reinstalling go ! \o/
BUT, I tried to do the same with two other popular softwares github.com/coreos/etcd and github.com/gogits/gogs => they both failed to install with the same error output…

This comment has been minimized.

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:

1. What version of Go are you using (`go version`)?
(already answered, skip)
2. What operating system and processor architecture are you using (`go env`)?
(already answered, skip)
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.
4. What did you expect to see?
5. What did you see instead?

In your case, the recipe must be a complete history of commands. Thanks.

This comment has been minimized.

After a while (five minutes ?) I hit ctrl+c to kill the script, then I run again the command

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.

This comment has been minimized.

edited

FYI, I ran again the ./g.sh script after the previous crash (#16136 (comment)) : this time it "freezed" at the stage below (65 minutes without output. Script is still "running" but does nothing). Here are the processes involved :

This comment has been minimized.

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 dmesg | grep CPU and dmesg | grep memory on your node is enough.

This comment has been minimized.

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 hw.vmm.vmx.use_apic_vid, sysctl hw.vmm.vmx.use_apic_vid=0 disables the functionality on the running kernel.

This comment has been minimized.

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.

This comment has been minimized.

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?

This comment has been minimized.

edited

Which exact FreeBSD version are you trying?

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.

This comment has been minimized.

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 :