Summary: | net-misc/curl: 'checking if getifaddrs seems to work' configure test hangs in app-emulation/qemu's qemu-user ppc32 (cURL getiffaddress() not functioning within qemu user chroot ppc32) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | germ <germtoo> |
Component: | Current packages | Assignee: | Matt Jolly <kangie> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | base-system, dilfridge, germtoo, kangie, releng, vidra.jonas, virtualization |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | Other | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
test to print getifaddress() functionality within qemu user chroot.
config.log Requested Build.log for curl-8.0.1 Requested Build.log for curl-8.0.1-ppc cURL compiled natively on ppc32muslgcc |
I think there's some more context here - please include the full build.log, config.log when building curl, and what's going wrong. I think I know what's happening here because Kangie mentioned it to me, but that doesn't make the bug report complete. Created attachment 870670 [details]
config.log
Requested config.log for curl-8.0.1-ppc.
Created attachment 870671 [details]
Requested Build.log for curl-8.0.1
Created attachment 870672 [details]
Requested Build.log for curl-8.0.1-ppc
Thanks. So, the initial issue (always good to start with that, even if you add more info in extra comments) is: the 'checking if getifaddrs seems to work' configure test hangs for curl with qemu-user ppc32. Now, you said you distilled the issue a bit into this C program: ``` #include <arpa/inet.h> #include <sys/socket.h> #include <ifaddrs.h> #include <stdio.h> int main () { struct ifaddrs *ifap, *ifa; struct sockaddr_in *sa; char *addr; getifaddrs (&ifap); for (ifa = ifap; ifa; ifa = ifa->ifa_next) { if (ifa->ifa_addr && ifa->ifa_addr->sa_family==AF_INET) { sa = (struct sockaddr_in *) ifa->ifa_addr; addr = inet_ntoa(sa->sin_addr); printf("Interface: %s\tAddress: %s\n", ifa->ifa_name, addr); } } freeifaddrs(ifap); return 0; } ``` Does this behave differently on native ppc32 vs qemu-user? I assume so. If so, please share the output of both. Created attachment 870762 [details]
cURL compiled natively on ppc32muslgcc
cURL compiled without getifaddress() stalling the compile.
The same issue – `configure` for curl hanging indefinitely when run in qemu-user – occurs on ppc64-musl too. I attached a debugger to QEMU, which shows that the program spins in musl, repeating the following two functions indefinitely: ``` netlink_msg_to_ifaddr (pctx=pctx@entry=0x407ff8e8, h=h@entry=0x407fd888) at src/network/getifaddrs.c:134 copy_lladdr (r=r@entry=0x408de82c, sa=sa@entry=0x408de840, addr=addr@entry=0x407fe214, addrlen=4294967292, ifindex=1, hatype=772) at src/network/getifaddrs.c:95 ``` The loop in `getifaddrs.c` never completes, because it doesn't actually advance the `rta` pointer. The pointed-to struct is empty: `{rta_len = 0, rta_type = 1}`, so the RTA_NEXT macro (https://git.musl-libc.org/cgit/musl/tree/src/network/netlink.h#n88) adds 0 to get the next item. I believe this is the same bug as described here: https://www.openwall.com/lists/musl/2018/05/30/4 I'll apply the patch from the linked thread and report whether it helped. (In reply to jonys from comment #7) > I'll apply the patch from the linked thread and report whether it helped. The patch has a trivial typo in it. The patched musl does allow curl to detect that `getifaddrs` works in the configure script and then compile cleanly. The compiled program seems to work, i.e. `curl --interface eth0 --head example.com` returns data. I assume this is what getifaddrs is used for internally. Also, running `ip addr list` from a qemu-ppc chroot results in ``` ip addr list !!!Deficit 4, rta_len=1024 !!!Deficit 4, rta_len=1024 !!!Deficit 4, rta_len=1024 !!!Deficit 4, rta_len=1024 !!!Deficit 4, rta_len=1024 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 255.255.255.127 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host proto kernel_lo valid_lft forever preferred_lft forever ``` My guess is that these messages are the result of the same underlying bug in QEMU syscall translation. Would you mind reporting this upstream and getting the patch merged there? (In reply to Matt Jolly from comment #9) > Would you mind reporting this upstream and getting the patch merged there? I'd love to, but I'm not entirely sure where to report it to. I'd say it's a bug in QEMU and the musl patch is more of a workaround than a fix. (In reply to jonys from comment #10) > (In reply to Matt Jolly from comment #9) > > Would you mind reporting this upstream and getting the patch merged there? > > I'd love to, but I'm not entirely sure where to report it to. I'd say it's a > bug in QEMU and the musl patch is more of a workaround than a fix. You will need to use gitlab to report bugs for QEMU. Thank you kindly for your work on this. In case anyone wonders, this is why catalyst is now running with a cpu time limit per process of 10h :o) |
Created attachment 870666 [details] test to print getifaddress() functionality within qemu user chroot. Compiling cURL from within qemu user chroot for PPC32 results in cURL's getifaddress function to stall while compiling. The following C program was tested within qemu user chroot with stage3 glibc gcc and stage3 musl gcc resulting in a functional printf for getiffadress().