This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Go patch committed: Update libgo to 1.1.1


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]