From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11100 invoked from network); 17 Feb 2022 04:14:33 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Feb 2022 04:14:33 -0000 Received: (qmail 29696 invoked by uid 550); 17 Feb 2022 04:14:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 28633 invoked from network); 17 Feb 2022 04:14:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BTtfhb+isYO4xlrs1DLavhWrzCbCexZzNGRj84v7CLk=; b=Em2P9GPlSDSHo5ipykQ+I6is651HHjRtrcoHqJdoumY08GUiE1+sy9YwvJQvpBOg55 y5PREvMq4ekybnHzHtMCgFQo3+zD4Uxs1VzO9DYGm2nXowwRUfK6m7f4PNNoq+yragPv 7FHEDE61BywYenuu7UMBSp5Bjh5d0yJatLL/xrvteF49HZ7Wb+p/8o1NJ050LstGpiZi l2GqE5AyvogxngXItUhGxTQLrKGu+omN/2v4nyHnb4mf4JLH65EJageebAy3M5hjzlIV /7JjTW4D0yHjEuIV/baEnUMz++pbhWeJJoR67GlfGrjYxrfeoY69B5jnaPnnV4/8FCiK /iMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BTtfhb+isYO4xlrs1DLavhWrzCbCexZzNGRj84v7CLk=; b=mPneepJtMwqgeBESD2DXo5cFMqQhDDrrmOTtVfH0sLDgH/x8Y5vjpF3hfUMKhGop03 4b13mYOkrcChHxI+CdkP9Tc1wwdd3cSPaCKXMdieeu3sP7sIr6NJy9URveU6ublwuyom 9fKvedW4qnzE4heons0lu1+hXjJ0+abRsKogNjiO/5PF1+V2nvG8oGPfIsAS8fC0nZXY kCxUz9cUuFS92ld8T6qxWZtdXCLBfuZG866FAbA6QNNW8HnoPlAAa9cfEWAGynA9dL9h Z0j0418TPBGeSG+e0xJutLEaPsecAhDFfZV4rQa1+gaeg39z8wOwOs9EPfn8USOBN0rN sToQ== X-Gm-Message-State: AOAM533ckc6SXF1keirjgxZqvGOR91h8UpKC8jJN+/03+OaulRbF1vpr ixAezE+aeVgNDFBx1fu9V+4abBxkiwZ3IhEenoHV4o+a X-Google-Smtp-Source: ABdhPJx3OFtNnd33AENj2pZDzkchOeq8z4Gl/ZCKjZa3u6m9gtiJdPhgLBz2403+FiUnWUPpvS2AwjSi98phx0TASdg= X-Received: by 2002:a05:6512:23a4:b0:437:5389:d30d with SMTP id c36-20020a05651223a400b004375389d30dmr811593lfv.311.1645071258716; Wed, 16 Feb 2022 20:14:18 -0800 (PST) MIME-Version: 1.0 References: <20220214182952.GI7074@brightrain.aerifal.cx> <20220214220043.GK7074@brightrain.aerifal.cx> <20220215174420.GL7074@brightrain.aerifal.cx> <20220216014153.GM7074@brightrain.aerifal.cx> <20220216213335.GO7074@brightrain.aerifal.cx> In-Reply-To: From: Satadru Pramanik Date: Wed, 16 Feb 2022 23:14:08 -0500 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000018ebb05d82f0015" Subject: Re: [musl] Re: musl getaddr info breakage on older kernels --000000000000018ebb05d82f0015 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oops. Looks like I reversed the patch wrong. Rebuilding again... On Wed, Feb 16, 2022 at 8:44 PM Satadru Pramanik wrote: > Looks like I need to do more than just reverse that commit to get this to > build... > > ../src_musl/src/internal/syscall.h:47:53: note: in expansion of macro > =E2=80=98__socketcall_cp=E2=80=99 47 | #define socketcall_cp(nm,a,b,c,= d,e,f) > __syscall_ret(__socketcall_cp(nm,a,b,c,d,e,f)) > | > ^~~~~~~~~~~~~~~ > ../src_musl/src/network/accept.c:6:16: note: in expansion of macro > =E2=80=98socketcall_cp=E2=80=99 > 6 | return socketcall_cp(accept, fd, addr, len, 0, 0, 0); > | ^~~~~~~~~~~~~ > ../src_musl/src/internal/syscall.h:62:54: note: each undeclared identifie= r > is reported only once for each function it appears in > 62 | #define __socketcall_cp(nm,a,b,c,d,e,f) > __syscall_cp(SYS_##nm, a, b, c, d, e, f) | > ^~~~ > ../src_musl/src/internal/syscall.h:55:53: note: in definition of macro > =E2=80=98__syscall_cp6=E2=80=99 55 | #define __syscall_cp6(n,a,b,c,d,= e,f) > (__syscall_cp)(n,__scc(a),__scc(b),__scc(c),__scc(d),__scc(e),__scc(f)) > | > ^ > ../src_musl/src/internal/syscall.h:57:27: note: in expansion of macro > =E2=80=98__SYSCALL_DISP=E2=80=99 57 | #define __syscall_cp(...) > __SYSCALL_DISP(__syscall_cp,__VA_ARGS__) | > ^~~~~~~~~~~~~~ > ../src_musl/src/internal/syscall.h:62:41: note: in expansion of macro > =E2=80=98__syscall_cp=E2=80=99 62 | #define __socketcall_cp(nm,a,b,= c,d,e,f) > __syscall_cp(SYS_##nm, a, b, c, d, e, f) | > ^~~~~~~~~~~~ > ../src_musl/src/internal/syscall.h:47:53: note: in expansion of macro > =E2=80=98__socketcall_cp=E2=80=99 > 47 | #define socketcall_cp(nm,a,b,c,d,e,f) > __syscall_ret(__socketcall_cp(nm,a,b,c,d,e,f)) > | > ^~~~~~~~~~~~~~~ > ../src_musl/src/network/accept.c:6:16: note: in expansion of macro > =E2=80=98socketcall_cp=E2=80=99 6 | return socketcall_cp= (accept, fd, addr, > len, 0, 0, 0); | ^~~~~~~~~~~~~ > ../src_musl/src/network/accept.c:7:1: warning: control reaches end of > non-void function [-Wreturn-type] > 7 | } > | ^ > make[2]: *** [Makefile:159: obj/src/network/accept.lo] Error= 1 > make[2]: Leaving directory > '/usr/local/tmp/crew/musl_native_toolchain.20220216215322.dir/build/local= /i686-linux-musl/obj_musl' > make[1]: *** [Makefile:24= 9: > obj_musl/.lc_built] Error 2 make[1]: > Leaving directory > '/usr/local/tmp/crew/musl_native_toolchain.20220216215322.dir/build/local= /i686-linux-musl' > make: *** > [Makefile:194: all] Error 2 > > On Wed, Feb 16, 2022, 4:53 PM Satadru Pramanik wrote: > >> I was looking at that commit too. I've started a build with that reverte= d >> and should be able to check back on that tomorrow. >> >> On Wed, Feb 16, 2022 at 4:33 PM Rich Felker wrote: >> >>> On Wed, Feb 16, 2022 at 01:44:35PM -0500, Satadru Pramanik wrote: >>> > The only change to socket.c I'm seeing is use __socketcall to simplif= y >>> > socket() >>> > < >>> https://git.musl-libc.org/cgit/musl/commit/?id=3D7063c459e7dbd63c2c94e0= 4413743abab5272001 >>> >, >>> > so maybe it would make sense for me to try building with that reverse= d? >>> >>> That should not be a functional change, but you may be overlooking >>> commit c2feda4e2ea61f4da73f2f38b2be5e327a7d1a91, which was: using the >>> new (added in 4.3) individual socket syscalls instead of the legacy >>> multiplexed SYS_socketcall. It's supposed to fall back to using the >>> old ones, but perhaps something goes wrong on your kernel that's >>> preventing it. I'm not sure what the mechanism by which it works when >>> straced/single-stepped could be, though, but if it's a weird kernel >>> bug anything is possible. >>> >>> Reverting that commit should be entirely safe, if it turns out to be >>> what's triggering your problem, but I'd like to get to the root cause >>> and see if there's anything we can do to ensure this doesn't come up >>> again. >>> >>> >>> > On Wed, Feb 16, 2022 at 1:37 PM Satadru Pramanik >>> wrote: >>> > >>> > > >>> > >> >>> > >> - Whether any network traffic occurs when it fails (in the real >>> > >> environment not a replicated one elsewhere). >>> > >> >>> > >> >>> > > There is no network traffic in the real environment. >>> > > >>> > > >>> > >> - Whether it fails or succeeds under strace (in the real >>> > >> environment not a replicated one elsewhere). >>> > >> >>> > >> It succeeds in strace (in the real environment) >>> > > >>> > > >>> > > >>> > >> - Whether the real environment involves Docker or not. >>> > >> >>> > >> The real environment does not involve docker. >>> > > >>> > > >>> > > >>> > >> - What's in resolv.conf (in the real environment not a replicated >>> one >>> > >> elsewhere) and what nameserver software (if known) is running on >>> the >>> > >> nameserver(s) listed in there. >>> > >> >>> > >> The nameserver is picked up from dhcp. The contents of the file ar= e >>> as >>> > > follows: >>> > > nameserver 192.168.0.1 >>> > > search lan. >>> > > options single-request timeout:1 attempts:5 >>> > > >>> > > >>> > >> - Anything else that might be relevant. >>> > >> >>> > >> DNS server is dnsmasq running on a current OpenWRT device. >>> > > >>> > > >>> > >> It's really hard to offer any productive advice when the problem i= s >>> > >> unclear. >>> > >> >>> > >> Apologies for the confusion. >>> > > I'm really just trying to debug this getaddrinfo breakage on this >>> older >>> > > hardware. The docker containers setup is something we use to build >>> packages >>> > > for this hardware, and our frustration is that the software works >>> perfectly >>> > > fine in the docker containers, but not on the hardware. >>> > > >>> > > > Any other suggestions on how to track down this issue? >>> > >> >>> > >> Rather than stepping through, I would put a single breakpoint at a >>> > >> place you want to see whether execution reaches before running the >>> > >> test program, then start it and see if the breakpoint fires or not= . >>> > >> Then remove the breakpoint, add a different one, and repeat. For >>> > >> example, see if __res_msend is ever called, and if so, whether >>> > >> particular lines of it are reached (or just put breakpoints on som= e >>> of >>> > >> the functions it calls, like socket, bind, recvfrom, poll, etc. to >>> see >>> > >> if they're called). >>> > >> >>> > >> It might also be useful to put a breakpoint on clock_gettime and >>> then >>> > >> 'finish' to see what it returns (in case the problem is something >>> > >> time64-related). >>> > >> >>> > >> >>> > > The only breakpoint which fixed the execution was for line 20 (whic= h >>> > > invokes getaddrinfo). Stepping through the __kernel_vsyscall and th= en >>> > > continuing is the only way it does not result in failure. >>> > > >>> > > Any later breakpoints fail. >>> > > >>> > > I went though the other breakpoints as requested. >>> > > clock_gettime did not fire. >>> > > >>> > > Breakpoint 1 at 0x5c2f7: file >>> ../src_musl/compat/time32/clock_gettime32.c, >>> > > line 9. >>> > > __res_msend, setsockopt also did not fire. >>> > > The ones that did fire were: socket, bind, recvfrom, poll, >>> __res_msend_rc, >>> > > memset, sendto, __get_resolv_conf, pthread_setcancelstate, >>> > > __pthread_setcancelstate, __lookup_serv, __lookup_name, memcpy >>> > > >>> > > When breaking on socket, stepping through the __kernel_vsyscall cal= l >>> after >>> > > socket and then continuing succeeds. >>> > > >>> > > Is it possible that the socket is not waiting long enough for a >>> response >>> > > from __kernel_vsyscall? Has that changed? >>> > > Breaking, stepping, and continuing on every other function above >>> fails. >>> > > >>> > > The gdb log is attached. >>> > > >>> > > Regards, >>> > > >>> > > Satadru >>> > > >>> > > >>> >> --000000000000018ebb05d82f0015 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oops. Looks like I reversed the patch wrong. Rebuilding ag= ain...

On Wed, Feb 16, 2022 at 8:44 PM Satadru Pramanik <satadru@gmail.com> wrote:
Looks like I need t= o do more than just reverse that commit to get this to build...

../src_musl/src/interna= l/syscall.h:47:53: note: in expansion of macro =E2=80=98__socketcall_cp=E2= =80=99=C2=A0 =C2=A0 47 | #define socketcall_cp(nm,a,b,c,d,e,f) __syscall_re= t(__socketcall_cp(nm,a,b,c,d,e,f))=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0^~~~~~~~~~~~~~~=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0../src_musl/src/network/accept.c:6:16: note: in expansion of macr= o =E2=80=98socketcall_cp=E2=80=99
=C2=A0 =C2=A0 6 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return socketcall_cp(accept, fd, addr, le= n, 0, 0, 0);
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^~~~~~~~~~~~~
../src_musl/src/internal/syscall.h:62:54: note: each undeclared identifier= is reported only once for each function it appears in=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A062 | #define __socketcall_cp(nm,a,b,c,d,e,f) __syscall_cp(SYS_= ##nm, a, b, c, d, e, f)=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ^~~~=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0../src_musl/src/internal/syscall.h:55:53: note: = in definition of macro =E2=80=98__syscall_cp6=E2=80=99=C2=A0 =C2=A0 =C2=A05= 5 | #define __syscall_cp6(n,a,b,c,d,e,f) (__syscall_cp)(n,__scc(a),__scc(b)= ,__scc(c),__scc(d),__scc(e),__scc(f))=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0^=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0../src_musl/src/internal/syscall.h:57= :27: note: in expansion of macro =E2=80=98__SYSCALL_DISP=E2=80=99=C2=A0 =C2= =A0 =C2=A057 | #define __syscall_cp(...) __SYSCALL_DISP(__syscall_cp,__VA_A= RGS__)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0^~~~~~~~~~~~~~=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ../src_musl/src/internal/syscall.h:62:41: n= ote: in expansion of macro =E2=80=98__syscall_cp=E2=80=99=C2=A0 =C2=A0 =C2= =A0 =C2=A062 | #define __socketcall_cp(nm,a,b,c,d,e,f) __syscall_cp(SYS_##n= m, a, b, c, d, e, f)=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^~~~~~~~~~~~=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ../src_musl/src/internal/syscall.h:47:53: note: in expansion of macro = =E2=80=98__socketcall_cp=E2=80=99
=C2=A0 =C2=A047 | = #define socketcall_cp(nm,a,b,c,d,e,f) __syscall_ret(__socketcall_cp(nm,a,b,= c,d,e,f))=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^~~~~~= ~~~~~~~~~=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0../src_musl/src/ne= twork/accept.c:6:16: note: in expansion of macro =E2=80=98socketcall_cp=E2= =80=99=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0return socketcall_cp(accept, fd, addr, len, 0, 0, 0);=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^~~~~~~~~~~~~
=
../src_musl/src/network/accept.c:7:1: warning: control re= aches end of non-void function [-Wreturn-type]=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A07 | }
=C2=A0 =C2=A0 =C2=A0 |= ^=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0make[2]: *** [Ma= kefile:159: obj/src/network/accept.lo] Error 1
make[= 2]: Leaving directory '/usr/local/tmp/crew/musl_native_toolchain.202202= 16215322.dir/build/local/i686-linux-musl/obj_musl'=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 make[1]: *** [Makefile:249: obj_musl/.lc_built] Error 2=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0make[1]: Leaving directory '/usr/local/t= mp/crew/musl_native_toolchain.20220216215322.dir/build/local/i686-linux-mus= l'=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0make: ***= [Makefile:194: all] Error 2

On Wed, Feb 16, 2022, 4:53 PM Satad= ru Pramanik <sata= dru@gmail.com> wrote:
I was looking at that commit too. I've st= arted a build with that reverted and should be able to check back on that t= omorrow.

On Wed, Feb 16, 2022 at 4:33 PM Rich Felker <dalias@aerifal.cx> wrote:
On = Wed, Feb 16, 2022 at 01:44:35PM -0500, Satadru Pramanik wrote:
> The only change to socket.c I'm seeing is use __socketcall to simp= lify
> socket()
> <https://git.musl-libc.org/cgit/musl/commit/?id=3D7063c459e7dbd63c2= c94e04413743abab5272001>,
> so maybe it would make sense for me to try building with that reversed= ?

That should not be a functional change, but you may be overlooking
commit c2feda4e2ea61f4da73f2f38b2be5e327a7d1a91, which was: using the
new (added in 4.3) individual socket syscalls instead of the legacy
multiplexed SYS_socketcall. It's supposed to fall back to using the
old ones, but perhaps something goes wrong on your kernel that's
preventing it. I'm not sure what the mechanism by which it works when straced/single-stepped could be, though, but if it's a weird kernel
bug anything is possible.

Reverting that commit should be entirely safe, if it turns out to be
what's triggering your problem, but I'd like to get to the root cau= se
and see if there's anything we can do to ensure this doesn't come u= p
again.


> On Wed, Feb 16, 2022 at 1:37 PM Satadru Pramanik <satadru@gmail.com<= /a>> wrote:
>
> >
> >>
> >> - Whether any network traffic occurs when it fails (in the re= al
> >>=C2=A0 =C2=A0environment not a replicated one elsewhere).
> >>
> >>
> > There is no network traffic in the real environment.
> >
> >
> >> - Whether it fails or succeeds under strace (in the real
> >>=C2=A0 =C2=A0environment not a replicated one elsewhere).
> >>
> >> It succeeds in strace (in the real environment)
> >
> >
> >
> >> - Whether the real environment involves Docker or not.
> >>
> >> The real environment does not involve docker.
> >
> >
> >
> >> - What's in resolv.conf (in the real environment not a re= plicated one
> >>=C2=A0 =C2=A0elsewhere) and what nameserver software (if known= ) is running on the
> >>=C2=A0 =C2=A0nameserver(s) listed in there.
> >>
> >> The nameserver is picked up from dhcp. The contents of the fi= le are as
> > follows:
> > nameserver 192.168.0.1
> > search lan.
> > options single-request timeout:1 attempts:5
> >
> >
> >> - Anything else that might be relevant.
> >>
> >> DNS server is dnsmasq running on a current OpenWRT device. > >
> >
> >> It's really hard to offer any productive advice when the = problem is
> >> unclear.
> >>
> >> Apologies for the confusion.
> > I'm really just trying to debug this getaddrinfo breakage on = this older
> > hardware. The docker containers setup is something we use to buil= d packages
> > for this hardware, and our frustration is that the software works= perfectly
> > fine in the docker containers, but not on the hardware.
> >
> > > Any other suggestions on how to track down this issue?
> >>
> >> Rather than stepping through, I would put a single breakpoint= at a
> >> place you want to see whether execution reaches before runnin= g the
> >> test program, then start it and see if the breakpoint fires o= r not.
> >> Then remove the breakpoint, add a different one, and repeat. = For
> >> example, see if __res_msend is ever called, and if so, whethe= r
> >> particular lines of it are reached (or just put breakpoints o= n some of
> >> the functions it calls, like socket, bind, recvfrom, poll, et= c. to see
> >> if they're called).
> >>
> >> It might also be useful to put a breakpoint on clock_gettime = and then
> >> 'finish' to see what it returns (in case the problem = is something
> >> time64-related).
> >>
> >>
> > The only breakpoint which fixed the execution was for line 20 (wh= ich
> > invokes getaddrinfo). Stepping through the __kernel_vsyscall and = then
> > continuing is the only way it does not result in failure.
> >
> > Any later breakpoints fail.
> >
> > I went though the other breakpoints as requested.
> > clock_gettime did not fire.
> >
> > Breakpoint 1 at 0x5c2f7: file ../src_musl/compat/time32/clock_get= time32.c,
> > line 9.
> > __res_msend, setsockopt also did not fire.
> > The ones that did fire were: socket, bind, recvfrom, poll, __res_= msend_rc,
> > memset, sendto, __get_resolv_conf, pthread_setcancelstate,
> > __pthread_setcancelstate, __lookup_serv, __lookup_name, memcpy > >
> > When breaking on socket, stepping through the __kernel_vsyscall c= all after
> > socket and then continuing succeeds.
> >
> > Is it possible that the socket is not waiting long enough for a r= esponse
> > from __kernel_vsyscall? Has that changed?
> > Breaking, stepping, and continuing on every other function above = fails.
> >
> > The gdb log is attached.
> >
> > Regards,
> >
> > Satadru
> >
> >
--000000000000018ebb05d82f0015--