On Thu, Oct 25, 2012 at 2:36 AM, Rainer Orth
wrote:
> Ian Lance Taylor writes:
>
>> There is a decent change that this will break something on non-x86
>> systems. I will do what testing I am able to do after the commit.
>
> As expected, it did break the Solaris libgo build:
>
> * udpsock_posix.g
Ian Lance Taylor writes:
> There is a decent change that this will break something on non-x86
> systems. I will do what testing I am able to do after the commit.
As expected, it did break the Solaris libgo build:
* udpsock_posix.go lacked definitions of joinIPv4Group, joinIPv6Group,
setIPv6M
Uros Bizjak writes:
> 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.
This is normal, gdb is leaking some fds to the inferior (which is a
bug).
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58
On Wed, Oct 24, 2012 at 11:03 AM, Ian Lance Taylor wrote:
>
> 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 Al
On Wed, Oct 24, 2012 at 10:52 AM, Uros Bizjak wrote:
> On Wed, Oct 24, 2012 at 7:46 PM, Ian Lance Taylor wrote:
>> On Wed, Oct 24, 2012 at 9:34 AM, Uros Bizjak wrote:
>>>
>>> Continuing.
>>> [New Thread 0x2000307b280 (LWP 8059)]
>>>
>>> Breakpoint 18, 0x020002e378c0 in socketpair () from /li
On Wed, Oct 24, 2012 at 7:46 PM, Ian Lance Taylor wrote:
> On Wed, Oct 24, 2012 at 9:34 AM, Uros Bizjak wrote:
>>
>> Continuing.
>> [New Thread 0x2000307b280 (LWP 8059)]
>>
>> Breakpoint 18, 0x020002e378c0 in socketpair () from /lib/libc.so.6.1
>>
>> Continuing.
>> [New Thread 0x20003083280 (
On Wed, Oct 24, 2012 at 9:34 AM, Uros Bizjak wrote:
>
> Continuing.
> [New Thread 0x2000307b280 (LWP 8059)]
>
> Breakpoint 18, 0x020002e378c0 in socketpair () from /lib/libc.so.6.1
>
> Continuing.
> [New Thread 0x20003083280 (LWP 8065)]
> [Switching to Thread 0x20003083280 (LWP 8065)]
>
> [...
On Wed, Oct 24, 2012 at 4:30 PM, Ian Lance Taylor wrote:
> On Wed, Oct 24, 2012 at 6:19 AM, Uros Bizjak wrote:
>> On Wed, Oct 24, 2012 at 3:10 PM, Ian Lance Taylor wrote:
>>> On Wed, Oct 24, 2012 at 5:31 AM, Uros Bizjak wrote:
On Wed, Oct 24, 2012 at 2:18 PM, Andreas Schwab
wrote:
>
On Wed, Oct 24, 2012 at 6:19 AM, Uros Bizjak wrote:
> On Wed, Oct 24, 2012 at 3:10 PM, Ian Lance Taylor wrote:
>> On Wed, Oct 24, 2012 at 5:31 AM, Uros Bizjak wrote:
>>> On Wed, Oct 24, 2012 at 2:18 PM, Andreas Schwab
>>> wrote:
Uros Bizjak writes:
> To answer my own question:
>
On Wed, Oct 24, 2012 at 3:10 PM, Ian Lance Taylor wrote:
> On Wed, Oct 24, 2012 at 5:31 AM, Uros Bizjak wrote:
>> On Wed, Oct 24, 2012 at 2:18 PM, Andreas Schwab
>> wrote:
>>> Uros Bizjak writes:
>>>
To answer my own question:
dup(4) = 9
...
On Wed, Oct 24, 2012 at 5:31 AM, Uros Bizjak wrote:
> On Wed, Oct 24, 2012 at 2:18 PM, Andreas Schwab wrote:
>> Uros Bizjak writes:
>>
>>> To answer my own question:
>>>
>>> dup(4) = 9
>>> ...
>>> close(9)= 0
>>> dup(4)
On Wed, Oct 24, 2012 at 2:18 PM, Andreas Schwab wrote:
> Uros Bizjak writes:
>
>> To answer my own question:
>>
>> dup(4) = 9
>> ...
>> close(9)= 0
>> dup(4) = -1 EBADF (Bad file descriptor)
>>
>> Te
Uros Bizjak writes:
> To answer my own question:
>
> dup(4) = 9
> ...
> close(9)= 0
> dup(4) = -1 EBADF (Bad file descriptor)
>
> Test is calling dup on a closed file descriptor.
FD 4 is most likely
On Wed, Oct 24, 2012 at 10:22 AM, Florian Weimer wrote:
>>> Is it OK to call dup on the same FD the second time?
>>
>>
>> To answer my own question:
>>
>> dup(4) = 9
>> ...
>> close(9)= 0
>> dup(4) =
On 10/24/2012 10:12 AM, Uros Bizjak wrote:
Is it OK to call dup on the same FD the second time?
To answer my own question:
dup(4) = 9
...
close(9)= 0
dup(4) = -1 EBADF (Bad file descriptor)
Test
On Wed, Oct 24, 2012 at 10:01 AM, Uros Bizjak wrote:
>>> Additional test fails on alphaev68-linux-gnu:
>>>
>>> --- FAIL: TestPassFD (0.15 seconds)
>>> passfd_test.go:62: FileConn: dup: Bad file descriptor
>>> FAIL
>>> FAIL: syscall
>>
>> As far as I can see this error message occurs when cal
On Wed, Oct 24, 2012 at 10:01 AM, Uros Bizjak wrote:
> On Tue, Oct 23, 2012 at 8:09 PM, Ian Lance Taylor wrote:
>> On Tue, Oct 23, 2012 at 10:47 AM, Uros Bizjak wrote:
>>>
>>> Additional test fails on alphaev68-linux-gnu:
>>>
>>> --- FAIL: TestPassFD (0.15 seconds)
>>> passfd_test.go:62: Fi
On Tue, Oct 23, 2012 at 8:09 PM, Ian Lance Taylor wrote:
> On Tue, Oct 23, 2012 at 10:47 AM, Uros Bizjak wrote:
>>
>> Additional test fails on alphaev68-linux-gnu:
>>
>> --- FAIL: TestPassFD (0.15 seconds)
>> passfd_test.go:62: FileConn: dup: Bad file descriptor
>> FAIL
>> FAIL: syscall
>
>
On Tue, Oct 23, 2012 at 10:47 AM, Uros Bizjak wrote:
>
> Additional test fails on alphaev68-linux-gnu:
>
> --- FAIL: TestPassFD (0.15 seconds)
> passfd_test.go:62: FileConn: dup: Bad file descriptor
> FAIL
> FAIL: syscall
As far as I can see this error message occurs when calling dup on the
On Tue, Oct 23, 2012 at 10:47 AM, Uros Bizjak wrote:
>
> On my x86_64-linux-gnu (Fedora 18) libgo testsuite fails following test:
>
> --- FAIL: TestCgoCrashHandler (0.01 seconds)
> testing.go:377: program exited with error: exec: "go":
> executable file not found in $PATH
> --- FAIL: TestC
Hello!
> I have committed a patch to update the mainline version of libgo to the
> current master Go library sources. At this point I will only be
> updating the gcc 4.7 branch for bug fixes.
>
> This is a substantial patch that brings in several months of work. As
> usual I am not posting the c
21 matches
Mail list logo
