This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Go patch committed: Update libgo to 1.1.1
- From: Ian Lance Taylor <iant at google dot com>
- To: Uros Bizjak <ubizjak at gmail dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "gofrontend-dev at googlegroups dot com" <gofrontend-dev at googlegroups dot com>
- Date: Wed, 24 Jul 2013 06:11:59 -0700
- Subject: Re: Go patch committed: Update libgo to 1.1.1
- References: <CAFULd4bbzWxorBWTW=QbjbdNuWVC1Fi0M0H3hWXyrwdBNn53eg at mail dot gmail dot com> <CAKOQZ8xjg8jK08x0X=q0iY+Hk8fdpbWH3UYSzV45qnAtVoGBMg at mail dot gmail dot com> <CAFULd4at+2GwMvv9wWJNbeBv2ny3vNer9+ratVhkBdfjTwVpHQ at mail dot gmail dot com> <CAFULd4aa+iWm+uASpNmpMdPH0=fCdicyz81Cj_7R=45YAvcpgQ at mail dot gmail dot com>
On Wed, Jul 24, 2013 at 2:24 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Wed, Jul 24, 2013 at 9:09 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>
>>>> The test was re-run with GOTESTFLAGS=--keep. When running the
>>>> resulting a.out with "strace -f -o strace-x86_64 ./a.out" from the
>>>> saved test directory, the test behaved in the same way as on alpha -
>>>> it hever finished. I have attached the resulting trace (the test was
>>>> killed with ctrl-c after some time).
>>>
>>> Thanks. The problematic test is TestLinuxSendfile in
>>> libgo/net/http/fs_test.go. That test binary invokes itself using
>>> strace. In the trace here, that strace fails:
>>>
>>> 8511 ptrace(PTRACE_TRACEME, 0, 0, 0) = -1 EPERM (Operation not permitted)
>>> 8511 write(2, "strace: test_ptrace_setoptions_f"..., 96) = 96
>>>
>>> The strace is supposed to start up a little server, and the test
>>> binary tries to connect to that server. Since the server hasn't
>>> started, the test times out.
>>>
>>> The strace invocation is
>>>
>>> strace -f -q -e trace=sendfile,sendfile64 ./a.out
>>> -test.run=TestLinuxSendfileChild
>>>
>>> Any idea why that would fail?
>
> It looks you can't trace a traced process:
>
> $ strace -f strace ./a.out
>
> [pid 17864] ptrace(PTRACE_TRACEME, 0, 0, 0) = -1 EPERM (Operation not permitted)
> [pid 17864] write(2, "strace: test_ptrace_setoptions_f"..., 93strace:
> test_ptrace_setoptions_for_all: PTRACE_TRACEME doesn't work: Operation
> not permitted
> ) = 93
> [pid 17864] exit_group(1) = ?
> [pid 17864] +++ exited with 1 +++
>
>> Manual invocation of this command tells us the reason. On alpha, it says:
>>
>> $ strace -f -e trace=sendfile64 ./a.out
>> strace: invalid system call 'sendfile64'
>>
>>> The Alpha stack trace you send also indicates a failure in this test.
>>> It could be for the same reason; hard to say. The Alpha strace output
>>> you send doesn't tell me much, since it wasn't done with -f.
>>
>> I have resent you the strace. The important part is:
>>
>> 7407 write(2, "strace: invalid system call 'sen"..., 41 <unfinished ...>
>> 7405 <... sigreturn resumed> ) = -1
>> 7407 <... write resumed> ) = 41
>> 7405 osf_sigprocmask(SIG_BLOCK, [] <unfinished ...>
>> 7407 exit_group(1) = ?
>> 7405 <... osf_sigprocmask resumed> ) = 0 (old mask [])
>> 7405 connect(7, {sa_family=AF_INET, sin_port=htons(32998),
>> sin_addr=inet_addr("127.0.0.1")}, 16) = 0
>> 7407 +++ exited with 1 +++
>>
>> The child exited with error, but this is not handled in the test, and
>> the test waits for dead process indefinitely.
>>
>> I think that the test should detect, if test system supports
>> sendfile64 and perhaps also handle invocation failure from the child
>> process.
>
> Attached patch fixes failures on alpha. However, the patch doesn't
> detect the failure from strace invocation, so the testcase could still
> wait for the dead child process.
>
> The patch was tested on x86_64-linux-gnu and alpha-linux-gnu.
Thanks a lot. Committed to mainline and 4.8 branch.
I looked at the kernel sources, and there does seem to be a sendfile64
system call on alpha (system call 239). I wonder how strace decides
which system calls are supported.
Ian