Bug 914256 – 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)

• Status: CONFIRMED
• Product: Gentoo Linux

[Description germ 2023-09-16 03:54:28 UTC]

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().

[Comment 1 Sam James 2023-09-16 03:55:28 UTC]

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.

[Comment 2 germ 2023-09-16 06:32:58 UTC]

Created attachment 870670 [details]
config.log

Requested config.log for curl-8.0.1-ppc.

[Comment 3 germ 2023-09-16 06:35:28 UTC]

Created attachment 870671 [details]
Requested Build.log for curl-8.0.1

[Comment 4 germ 2023-09-16 06:36:05 UTC]

Created attachment 870672 [details]
Requested Build.log for curl-8.0.1-ppc

[Comment 5 Sam James 2023-09-16 06:39:50 UTC]

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.

[Comment 6 germ 2023-09-16 18:11:08 UTC]

Created attachment 870762 [details]
cURL compiled natively on ppc32muslgcc

cURL compiled without getifaddress() stalling the compile.

[Comment 7 jonys 2024-03-09 16:19:20 UTC]

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.

[Comment 8 jonys 2024-03-09 17:16:21 UTC]

(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.

[Comment 9 Matt Jolly 2024-03-10 01:16:11 UTC]

Would you mind reporting this upstream and getting the patch merged there?

[Comment 10 jonys 2024-03-11 07:34:00 UTC]

(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.

[Comment 11 germ 2024-03-12 08:29:16 UTC]

(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.

[Comment 12 Andreas K. Hüttel 2024-04-29 23:20:18 UTC]

In case anyone wonders, this is why catalyst is now running with a cpu time limit per process of 10h :o)