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 10:52 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Wed, Oct 24, 2012 at 7:46 PM, Ian Lance Taylor <iant@google.com> wrote:
>> 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?
>
> 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