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 25373 invoked from network); 17 Feb 2022 01:44:29 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Feb 2022 01:44:29 -0000 Received: (qmail 26148 invoked by uid 550); 17 Feb 2022 01:44:26 -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 26109 invoked from network); 17 Feb 2022 01:44:26 -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=kzUQiREMW6rr8Pu4KQu5E96iUwCxoaZdQdB2iyYZ6qw=; b=EFnEtiFxG0T0CZsuGlY723ZZksCwm3b474FNVVue3eMCQJUnYKXBFCJRXzp7BE6Kv2 CiH/KU81+X1iEWQ0ye2Ubz6YzvGyJx8+OrLJssWyszIjGQyujv/J77XGYjXRJRAmTQJu 2sVlHLSWd18LRyt7soNXU4omMJymYT5xOoPvcrx0C5GQMaaJz9hSN+VQWDurHgjljDZx +g4u3/VNQf1G8BUeo2hMEZi5+xvOU+CIh1HFqD/rCjqHcbOQ1G7Uy7PHIC5qbbeoe9O7 IXhHh3xciZ7SIKmKyVQMmJGaIBfLED/d1zg7xgoLg5epOXYbJSI1RsXu+6kvOHHOE/bD 80ug== 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=kzUQiREMW6rr8Pu4KQu5E96iUwCxoaZdQdB2iyYZ6qw=; b=n6oycYV91dxawvwK+JB6VXhW+YyWEJ6g+u+2fdydQYNcY7AZWaqGVInPD0BBQ9wlyZ 8S7vyc68hwrgdXVwBFYygXPCqR2SkiqJtYamseRBW4VMoFFMQJHz7dPeAYJZxjxnuABa 5gNsyY1knFBSx3rvHkIOEr4gb3/P3kXJSw6KELTcKDbp3nDzUNXOGEDJEvYcoa5OqUCF 4lcodKQC2PSrmv4mb/3r5dKReacW6zp4YTCc9sJaH6W+2maRiTf9jMcHVJs/lGfKEVl+ 8zwZOuJcdeirznpU+rcPashCboaE4NY9QdyR/eYV0HTjrIMsPnS7TjgFmrGoPKC51e58 Irvg== X-Gm-Message-State: AOAM533KD++OOcxeS9hhUJyJ7sHwQ9BTP9oFVtPlGPpKAbFg1j88OcGA YcBYWmxY0t/yhvGCkhKKvBm9xRkdApf3tKpWVUF0g8HD X-Google-Smtp-Source: ABdhPJz77nnLEZ0omMOA8XneDtbWTXfoyQwQNCPLaia8e/FTGfruz6eb+A38NvE7EM33L4dYNeNCho1kRBUVTu+SI/o= X-Received: by 2002:a05:6512:332a:b0:443:77b5:d917 with SMTP id l10-20020a056512332a00b0044377b5d917mr569250lfe.386.1645062253902; Wed, 16 Feb 2022 17:44:13 -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 20:44:03 -0500 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="00000000000046fff105d82ce7fc" Subject: Re: [musl] Re: musl getaddr info breakage on older kernels --00000000000046fff105d82ce7fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 identifier 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(a= ccept, 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/i= 686-linux-musl/obj_musl' make[1]: *** [Makefile:249: obj_musl/.lc_built] Error 2 make[1]: Leaving directory '/usr/local/tmp/crew/musl_native_toolchain.20220216215322.dir/build/local/i= 686-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 reverted > 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 simplify >> > socket() >> > < >> https://git.musl-libc.org/cgit/musl/commit/?id=3D7063c459e7dbd63c2c94e04= 413743abab5272001 >> >, >> > 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 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 o= ne >> > >> 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 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 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 some >> 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 th= en >> > >> '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 (which >> > > invokes getaddrinfo). Stepping through the __kernel_vsyscall and the= n >> > > 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 call >> 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 >> > > >> > > >> > --00000000000046fff105d82ce7fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looks like I need to do more than just reverse that commi= t 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=C2=A0 =C2=A0 47 | #define socket= call_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/network/acc= ept.c:6:16: note: in expansion of macro =E2=80=98socketcall_cp=E2=80=99
=C2=A0 =C2=A0 6 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0retu= rn 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 ^~~~~~~~~~~~~
../src_musl/src/internal/syscall.h= :62:54: note: each undeclared identifier is reported only once for each fun= ction 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 __socketca= ll_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/s= rc/internal/syscall.h:55:53: note: in definition of macro =E2=80=98__syscal= l_cp6=E2=80=99=C2=A0 =C2=A0 =C2=A055 | #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_ARGS__)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^~~~~~~~~~~~~= ~=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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_m= usl/src/internal/syscall.h:62:41: note: in expansion of macro =E2=80=98__sy= scall_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_##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 ../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) __sysca= ll_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/network/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 reaches end of non-void function [-Wreturn-t= ype]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=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]: *** [Makefile:159: obj/src/network/accept.lo] Err= or 1
make[2]: Leaving directory '/usr/local/tmp/= crew/musl_native_toolchain.20220216215322.dir/build/local/i686-linux-musl/o= bj_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]: Leav= ing directory '/usr/local/tmp/crew/musl_native_toolchain.20220216215322= .dir/build/local/i686-linux-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 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0make: *** [Makefile:194: all] Error 2

On= Wed, Feb 16, 2022, 4:53 PM Satadru Pramanik <satadru@gmail.com> wrote:
I was looking at that commit too. I've starte= d a build with that reverted and should be able to check back on that tomor= row.

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
> >
> >
--00000000000046fff105d82ce7fc--