Message ID | CAFULd4akD1Ba4FJ2-Kvvdt4Rwwdmj-Kspge-tKvBWgHwSPWj6A@mail.gmail.com |
---|---|
State | New |
Headers | show |
Uros Bizjak <ubizjak@gmail.com> writes: > Attached is the patch I have committed. Thanks for taking care of that. > (BTW: Do you have any idea on what to do with excessive memory usage > in chan/select2.go? ) At this point I don't. It's sort of peculiar. Sending an int on a channel should not use any memory. The test is careful to only measure the memory allocated for sending and receiving, and as far as I can see nothing else should be allocated during the test. You reported that the test was allocating 2098576 bytes. When I run it I see it allocating 1408 bytes on x86_64, 640 bytes on i386. 2098576 is much larger than either number. What is allocating that memory? In other words, there appears to be a real bug here. You can probably track it down by setting a breakpoint on runtime_mallocgc after the line runtime.MemStats.Alloc = 0 What is calling runtime_mallocgc? Ian
Index: go.test/go-test.exp =================================================================== --- go.test/go-test.exp (revision 183805) +++ go.test/go-test.exp (working copy) @@ -305,6 +305,14 @@ } } + # Handle certain tests in a target-dependant way. + if [istarget "alpha*-*-*"] { + if { [string match "*go.test/test/nilptr.go" $test] } { + go-execute-xfail $test + continue + } + } + if { [string match "*bug347*" $test] \ || [string match "*bug348*" $test] } { # These bugs rely on runtime.Caller which currently fails.