Comment 1:

On the machines that I have, the test works correctly on both NetBSD 6.0 BETA2 amd64 and
i386. Unfortunately there is insufficient information in this bug report to know
anything about your environment, however there is a good chance it is related to a
timecounter issue or the process being starved of CPU time. If I had to guess, I'd say
that you're probably running on a (badly?) virtualised platform.
Is this 100% repeatable?
Is this on a virtualised or physical machine? If virtualised, what platform?
Is this a single or multiprocessor machine?

Status changed to WaitingForReply.

Comment 2 by raul.san@sent.com:

I just compile it again, and it was ok, so it is not 100 repeatable; but you have in
mind that, the another date, when I was compiling  Go in several VMs (once at time), the
only OS that shows that error was NetBSD.
Now, the time test took:
ok      time    26.393s
The only error that I have now is:
run        nilptr.go           : incorrect output
fork/exec /tmp/go-build767292044/command-line-arguments/_obj/a.out: cannot allocate
memory
I've to change ulimit -d
* * *
This is into a VM; VirtualBox 4.1.12 over Ubuntu 12.04. The VM has RAM 256M limited to 1
processor with execution capacity of until 95%.
Note that I've used the same VM configuration for systems FreeBSD, NetBSD and OpenBSD;
and the only difference is that NetBSD uses 256M RAM while Free/Open BSD have 192M RAM.
The host CPU (not VM) is:
CPU0: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz stepping 07

Comment 3 by raul.san@sent.com:

I just install the last Go devel version, 2012-08-16, in the last NetBSD release, 6.0
RC1, and it works ok.
Using ulimit -n256, ulimit -d 524288, like it is indicated here[1]
[1] http://code.google.com/p/go-wiki/wiki/NetBSD

Comment 4 by raul.san@sent.com:

The Go verions is to 2012-09-02 date.

Comment 5 by raul.san@sent.com:

I don't understand the why, but I've re-compiled Go after of restart NetBSD and it fails
in exp/types
*** Test killed: ran too long.
FAIL    exp/types       180.006s

Comment 6:

Does this issue only occur when you run NetBSD inside VirtualBox ?

Comment 7:

I also run NetBSD inside vbox, and all.bash could pass.

Comment 8 by raul.san@sent.com:

I've been doing some tests in BSD systems from VirtualBox.
Re-compiling in systems FreeBSD and Darwin is Ok, but it fails in systems where there is
to change the ulimits (it could be a coincidence):
+ OpenBSD (ulimit -n 256)
# GOMAXPROCS=2 runtime -cpu=1,2,4
*** Test killed: ran too long.
FAIL    runtime 326.996s
+ NetBSD (ulimit -n 256; ulimit -d 524288)
*** Test killed: ran too long.
FAIL    exp/types       180.695s
So, I removed the Go source directory and untar it to compile from a "new directory",
and the issue is fixed in NetBSD, so it is not issue related to VirtualBox, I think.
In change, the OpenBSD issue is not solved removing the Go source directory.
Note: NetBSD called my attention since it is the only system that shows a line with
"scatter"
# ../misc/cgo/test
scatter = 0x42a3bc
PASS
ok      _/home/neo/go-src/misc/cgo/test 1.663s

Comment 9:

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

Comment 10 by raul.san@sent.com:

Solved in Go 1.1rc1 and tested with hte lasts BSD* distros.

Comment 11:

Thanks for confirming.

Status changed to Fixed.