On Wed, Oct 24, 2012 at 10:52 AM, Uros Bizjak <ubiz...@gmail.com> wrote: > On Wed, Oct 24, 2012 at 7:46 PM, Ian Lance Taylor <i...@google.com> wrote: >> On Wed, Oct 24, 2012 at 9:34 AM, Uros Bizjak <ubiz...@gmail.com> wrote: >>> >>> Continuing. >>> [New Thread 0x2000307b280 (LWP 8059)] >>> >>> Breakpoint 18, 0x0000020002e378c0 in socketpair () from /lib/libc.so.6.1 >>> >>> Continuing. >>> [New Thread 0x20003083280 (LWP 8065)] >>> [Switching to Thread 0x20003083280 (LWP 8065)] >>> >>> [...] >>> >>> The first call with relevant FD is from: >>> >>> Breakpoint 21, 0x0000020002e243f8 in close () from /lib/libc.so.6.1 >>> (gdb) i r a0 >>> a0 0x8 8 >> >> Does this mean that this is a call to close file descriptor 8? >> According to the strace log, the file descriptor we care about is 4. >> Although it is also true that I don't see a close of file descriptor 8 >> at all in the strace log. Or is the change from 4 to 8 due somehow to >> running the program under gdb? > > Yes, I am running under gdb and all FDs are offset by +4 for some > reason. So, FD 8 corresponds to FD4 in the strace log. >> >>> (gdb) bt >>> #0 0x0000020002e243f8 in close () from /lib/libc.so.6.1 >>> #1 0x000000012003559c in syscall.Close (fd=<optimized out>) at >>> libcalls.go:271 >>> #2 0x00000200005d3cfc in os.close.pN7_os.file (file=0xf840414b70) at >>> ../../../gcc-svn/trunk/libgo/go/os/file_unix.go:106 >>> #3 0x0000020000888f18 in ffi_call_osf () at >>> ../../../gcc-svn/trunk/libffi/src/alpha/osf.S:79 >>> #4 0x00000200008889c4 in ffi_call (cif=<optimized out>, fn=<optimized >>> out>, rvalue=<optimized out>, avalue=0xf840c87fe8) >>> at ../../../gcc-svn/trunk/libffi/src/alpha/ffi.c:169 >>> #5 0x0000020000558204 in reflect.call (func_type=0x200009e9650 >>> <__go_td_FppN7_os.fileerN5_erroree>, >>> func_addr=0x200005d3c60 <os.close.pN7_os.file>, >>> is_interface=<optimized out>, is_method=<optimized out>, >>> params=0xf840c87fe0, results=0x0) at >>> ../../../gcc-svn/trunk/libgo/runtime/go-reflect-call.c:498 >>> #6 0x00000200005620b8 in runfinq (dummy=<optimized out>) at >>> ../../../gcc-svn/trunk/libgo/runtime/mgc0.c:1168 >>> #7 0x0000020000566b20 in kickoff () at >>> ../../../gcc-svn/trunk/libgo/runtime/proc.c:338 >>> #8 0x0000020002d8d024 in ?? () from /lib/libc.so.6.1 >> >> If this is indeed the file descriptor we care about, then this is >> interesting, because it is being closed by a finalizer run by the >> garbage collector. That implies that the garbage collector collected >> the local variable readFile in TestPassFD in passfd_test.go, which >> would be clearly wrong. Unfortunately this could be rather difficult >> to debug. > > Yes, this is correct descriptor. For added fun, a descriptor that > corresponds to writeFile closes through the same mechanism.
OK, so it's a garbage collector problem. Can you e-mail me the test binary offlist? I will try to figure out where readFile lives. The fact that I'm not seeing any GC problems on x86 or x86_64 suggests that this is something Alpha-specific. Or, it could be something specific to the non-split-stack code. What's weird is that it's unlikely to be a major error, since most of your tests pass. Ian