bug in chan/select2.go?

169 views
Skip to first unread message

Dorival Pedroso

unread,
Oct 16, 2012, 7:20:28 PM10/16/12
to golan...@googlegroups.com
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

unread,
Oct 16, 2012, 7:21:19 PM10/16/12
to Dorival Pedroso, golan...@googlegroups.com
Which os/architecture ? which revision of Go ?
> --
>
>

Dorival Pedroso

unread,
Oct 16, 2012, 7:45:47 PM10/16/12
to golan...@googlegroups.com, 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

unread,
Oct 17, 2012, 2:48:09 AM10/17/12
to Dorival Pedroso, golan...@googlegroups.com
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

unread,
Oct 19, 2012, 8:27:22 PM10/19/12
to golan...@googlegroups.com, 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

unread,
Oct 19, 2012, 8:28:19 PM10/19/12
to golan...@googlegroups.com, Dorival Pedroso
by the way, hg iden:
ababb5c0cc6b+ tip

Dorival Pedroso

unread,
Oct 20, 2012, 8:54:13 PM10/20/12
to golan...@googlegroups.com
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

unread,
Oct 20, 2012, 8:58:55 PM10/20/12
to Dorival Pedroso, golan...@googlegroups.com

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

unread,
Oct 20, 2012, 11:26:11 PM10/20/12
to golan...@googlegroups.com, Dorival Pedroso
i've just completely deleted my go directory:

rm -rf 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

unread,
Oct 20, 2012, 11:48:44 PM10/20/12
to Dorival Pedroso, golan...@googlegroups.com, Dorival Pedroso
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

unread,
Oct 21, 2012, 12:15:32 AM10/21/12
to golan...@googlegroups.com, 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

unread,
Oct 21, 2012, 1:21:35 AM10/21/12
to Dorival Pedroso, Albert Strasheim, golan...@googlegroups.com
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

unread,
Oct 21, 2012, 1:38:06 AM10/21/12
to Dave Cheney, Albert Strasheim, golan...@googlegroups.com, Dorival Pedroso


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

unread,
Oct 21, 2012, 1:41:48 AM10/21/12
to minux, Albert Strasheim, golan...@googlegroups.com, Dorival Pedroso
If both of those conditions are true, then I agree, run.bash should
unset GOMAXPROCS before running the tests in $GOROOT/test/
Reply all
Reply to author
Forward
0 new messages