bug in chan/select2.go?

[Dorival Pedroso]

hi all, i'm just wondering if i'm doing something wrong when compiling go since i'm getting:

# ../test

run        chan/select2.go     : incorrect output

BUG: too much memory for 100,000 selects: 103456

[Dave Cheney]

Which os/architecture ? which revision of Go ?

> --
>
>

[Dorival Pedroso]

sure.

hg iden:

7fe634e0f93e tip

uname -a:

Linux hname 3.2.0-4-rt-amd64 #1 SMP PREEMPT RT Debian 3.2.30-1 x86_64 GNU/Linux

[minux]

On Wed, Oct 17, 2012 at 7:45 AM, Dorival Pedroso <dorival...@gmail.com> wrote:

hg iden:

7fe634e0f93e tip

uname -a:

Linux hname 3.2.0-4-rt-amd64 #1 SMP PREEMPT RT Debian 3.2.30-1 x86_64 GNU/Linux

RT? I've never tried Go on RT Linux. But I don't understand why test/chan/select2.go fails

on RT Linux either. Perhaps gopher is warning us that it's not RT-capable in its own ways ;-)

[Dorival Pedroso]

same problem with no rt kernel:

# ../test

run        chan/select2.go     : incorrect output

BUG: too much memory for 100,000 selects: 103456

exit status 1

uname -a:

Linux hname 3.2.0-4-amd64 #1 SMP Debian 3.2.30-1 x86_64 GNU/Linux

dual Intel(R) Xeon(R) CPU E5-2687W 0 @ 3.10GHz 8-cores machine...

[Dorival Pedroso]

by the way, hg iden:

ababb5c0cc6b+ tip

[Dorival Pedroso]

just a follow-up on this, by running ./run within go/test:

bug: chan/select2.go

3a4,14

> =========== ./index.go

> tmp.go:223: slice index out of bounds

> tmp.go:224: slice index out of bounds

> tmp.go:225: slice index out of bounds

> tmp.go:225: constant -2147483638 overflows uint64

> tmp.go:226: slice index out of bounds

> tmp.go:226: constant -2147483638 overflows uint64

> tmp.go:228: slice index out of bounds

> tmp.go:229: slice index out of bounds

> tmp.go:229: too many errors

> 

6a18,20

> 

> =========== chan/select2.go

> BUG: too much memory for 100,000 selects: 103456

1 known bugs; 1 unexpected bugs; test output differs

FAILED

hg iden:

6653eb72fd46 tip

uname -a:

Linux hname 3.2.0-4-amd64 #1 SMP Debian 3.2.30-1 x86_64 GNU/Linux

[Dave Cheney]

Hi,

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.

Cheers

Dave

--
 
 

[Dorival Pedroso]

i've just completely deleted my go directory:

rm -rf go

hg clone https://code.google.com/p/go

cd go/src/

hg iden

6653eb72fd46 tip

then:

./all.bash

the error persists:

# ../test

run        chan/select2.go     : incorrect output

BUG: too much memory for 100,000 selects: 103456

i'm happy to try to find where the problem is but just don't know where to look at...

cheers.

dorival

[Dave Cheney]

Are you sure you don't have another 'go' binary higher up in your path, or GO{ROOT,OS,ARCH} set incorrectly (not setting them is also valid)

--
 
 

[Dorival Pedroso]

ok, i've found it!

this fixes the problem:

unset GOMAXPROCS

ok, i've had: GOMAXPROCS=32 since my machine is a dual 8-core smp... anyway, apparently it doesn't work with GOMAXPROCS=8 either... (4 is ok)

just a note: GOROOT and the other path vars seem to be all right...

many thanks for your help!

cheers

dorival

[Dave Cheney]

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.

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.

Cheers

Dave

> --
>
>

[minux]

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.

[Dave Cheney]

If both of those conditions are true, then I agree, run.bash should
unset GOMAXPROCS before running the tests in $GOROOT/test/