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? > (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. Ian