This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: libgo patch committed: Update to current Go library
On Wed, Oct 24, 2012 at 9:34 AM, Uros Bizjak <ubizjak@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