On Wed, Feb 1, 2012 at 10:59 PM, Uros Bizjak <ubiz...@gmail.com> wrote:
> On Wed, Feb 1, 2012 at 10:27 PM, Ian Lance Taylor <i...@google.com> wrote:
>
>>> (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?
Some more debugging reveal the difference between alpha and x86_64.
Alpha does not implement split stacks, so soon after
"runtime.MemStats.Alloc = 0" line, we allocate exactly 2MB fake stack
via:
Breakpoint 5, runtime_mallocgc (size=2097152, flag=6, dogc=0,
zeroed=0) at ../../../gcc-svn/trunk/libgo/runtime/malloc.goc:41
41 m = runtime_m();
(gdb) bt
#0 runtime_mallocgc (size=2097152, flag=6, dogc=0, zeroed=0) at
../../../gcc-svn/trunk/libgo/runtime/malloc.goc:41
#1 0x000002000050d4b0 in runtime_malg (stacksize=<optimized out>,
ret_stack=0xf840205f70, ret_stacksize=0xf840205f68)
at ../../../gcc-svn/trunk/libgo/runtime/proc.c:1166
#2 0x000002000050e3b8 in __go_go (fn=0x1200016b0 <main.$thunk1>,
arg=0xf8400001f0) at ../../../gcc-svn/trunk/libgo/runtime/proc.c:1218
#3 0x0000000120001968 in main.main () at select2.go:46
#4 0x000002000050e800 in runtime_main () at
../../../gcc-svn/trunk/libgo/runtime/proc.c:371
So, short of XFAILing the test on non-split stack targets, I have no
other idea how to handle this testcase failure.
Uros.
