hg iden:7fe634e0f93e tipuname -a:Linux hname 3.2.0-4-rt-amd64 #1 SMP PREEMPT RT Debian 3.2.30-1 x86_64 GNU/Linux
I'm concerned about this as you have been able to reproduce the problem consistently. However none of the Ci builders have reported similar issues.
Is it possible that you have multiple versions of Go installed and visible in your path?
Are you in a position to reproduce this issue on another machine?
If you can still reproduce the failure, I suggest you raise an issue on the go issue tracker.
On Oct 21, 2012 1:21 PM, "Dave Cheney" <da...@cheney.net> wrote:
> Glad you found the problem. Memory accounting is tricky when there is
> more than one active goroutine, I think if you search the mailing list
> archive there is a report from 6 to 12 months ago of other tests being
> unreliable in that circumstance.
i think we should unset GOMAXPROCS in run.bash
to prevent future frustrations.
> One regular contributor runs a continual stress test build with random
> GOMAXPROCS values so I am surprised that this problem hasn't shown up
> earlier. I've cc'd him to see if his methodology is different.
iirc, fullung said he only stress tests all the packages tests
with random GOMAXPROCS.