Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADFzTtee6znNveAz_fWC6n8RtQsOsG6z8SvmHjCG0eaod-FMJA@mail.gmail.com>
Date: Tue, 19 Jan 2021 12:56:33 -0800
From: Rasmus Andersson <rasmus@...ion.se>
To: musl@...ts.openwall.com
Subject: Re: waitpid (wait4) on Linux 5 returns invalid values

waitpid works as expected after building musl 1.2.1 and GCC 9.2.0 from source.
It must be so that the binary distributions at
https://musl.cc/#binaries are broken somehow.
$ /build/gcc-x86_64-linux-musl/bin/x86_64-linux-musl-gcc -static a.c && ./a.out
waitpid returned -1, wstat=0, errno=10 "No child process"

Markus thank you for pointing me in the right direction :-)

On Tue, Jan 19, 2021 at 12:35 PM Rasmus Andersson <rasmus@...ion.se> wrote:
>
> Relevant parts from disassembly: (objdump --disassemble --source
> --line-numbers a.out)
>
> 0000000000401f61 <__syscall_cp_c>:
> sccp():
>   401f61: 48 89 f8              mov    %rdi,%rax
>   401f64: 4d 89 c2              mov    %r8,%r10
>   401f67: 48 89 f7              mov    %rsi,%rdi
>   401f6a: 4d 89 c8              mov    %r9,%r8
>   401f6d: 48 89 d6              mov    %rdx,%rsi
>   401f70: 4c 8b 4c 24 08        mov    0x8(%rsp),%r9
>   401f75: 48 89 ca              mov    %rcx,%rdx
>   401f78: 0f 05                 syscall
>   401f7a: c3                    retq
>
> 0000000000401f7b <__syscall_cp>:
> __syscall_cp():
>   401f7b: e9 e1 ff ff ff        jmpq   401f61 <__syscall_cp_c>
>
> 00000000004004fd <waitpid>:
> waitpid():
>   ...
>   40051a: e8 5c 1a 00 00        callq  401f7b <__syscall_cp>
>   40051f: 48 83 c4 18           add    $0x18,%rsp
>   400523: c3                    retq
>
> main():
>   ...
>   4002a2: e8 56 02 00 00        callq  4004fd <waitpid>
>
> On Tue, Jan 19, 2021 at 12:28 PM Rasmus Andersson <rasmus@...ion.se> wrote:
> >
> > In the meantime, in case you're curious, here's a program that
> > reproduces the issue. I've attached a statically-compiled version too
> > that can be disassembled. Running it:
> > $ gcc -static a.c && ./a.out
> > waitpid returned -10, wstat=0
> >
> > #include <sys/wait.h>
> > #include <stdio.h>
> > int main(int argc, char **argv) {
> >         int wstat = 0;
> >         pid_t child = waitpid(-1, &wstat, WNOHANG);
> >         printf("waitpid returned %d, wstat=%d\n", child, wstat);
> >         return 0;
> > }
> >
> > On Tue, Jan 19, 2021 at 12:17 PM Rasmus Andersson <rasmus@...ion.se> wrote:
> > >
> > > On Tue, Jan 19, 2021 at 11:33 AM Markus Wichmann <nullplan@....net> wrote:
> > > >
> > > > On Tue, Jan 19, 2021 at 10:18:04AM -0800, Rasmus Andersson wrote:
> > > > > However the wait4 syscall[3] in Linux 5 returns other values,
> > > > > specifically it returns errors as negative values. The error that
> > > > > trips up programs like runit's runsv is ECHILD (-10) which wait4
> > > > > returns when there are no children (i.e. they have exited.)
> > > > >
> > > >
> > > > Hmm... that is very weird. That should not happen. Because the
> > > > syscall_cp macro already contains a call to __syscall_ret(), which does
> > > > exactly what you propose. So that means, there is something else going
> > > > on in your copy of the code. Did you change anything about the source
> > > > code? Or can you disassemble the function to see what it does?
> > > >
> > > Strange! You are right of course; looking at src/internal/syscall.h I
> > > indeed see that syscall_cp calls __syscall_ret(__syscall_cp(args))
> > > The musl I'm building with comes from https://musl.cc/#binaries which
> > > is created from these scripts according to the author:
> > > https://git.zv.io/xstatic/mcm It doesn't seem to apply any patches.
> > > Anyhow, I'm currently building musl & gcc myself using
> > > musl-cross-make. I will see how that pans out and report back.
> > > Thank you for your quick response Markus!

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.