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? The backtrace says: After a couple of calls from __go_new_channel, __go_new,__go_alloc, the test starts to loop with allocations from newselect: Breakpoint 2, runtime_mallocgc (size=156, flag=0, dogc=1, zeroed=1) at ../../../gcc-svn/trunk/libgo/runtime/malloc.goc:41 41 m = runtime_m(); (gdb) bt #0 runtime_mallocgc (size=156, flag=0, dogc=1, zeroed=1) at ../../../gcc-svn/trunk/libgo/runtime/malloc.goc:41 #1 0x0000020000510364 in runtime_mal (n=156) at ../../../gcc-svn/trunk/libgo/runtime/malloc.goc:414 #2 0x0000020000506424 in newselect (selp=<synthetic pointer>, size=2) at ../../../gcc-svn/trunk/libgo/runtime/chan.c:644 #3 runtime.newselect (size=<optimized out>) at ../../../gcc-svn/trunk/libgo/runtime/chan.c:c630 #4 0x0000000120001634 in main.receiver (c=0xf84020e000, dummy=0xf84020e7c0, n=100000) at /space/uros/gcc-svn/trunk/gcc/testsuite/go.test/test/chan/select2.go:19 #5 0x0000000120001824 in main.main () at /space/uros/gcc-svn/trunk/gcc/testsuite/go.test/test/chan/select2.go:36 I didn't check where memory gets de-allocated, but there are really a lot of above calls. Uros.