1 files changed, 62 insertions, 0 deletions
diff --git a/results/classifier/108/other/2485 b/results/classifier/108/other/2485
new file mode 100644
index 000000000..63fb0e895
--- /dev/null
+++ b/results/classifier/108/other/2485
@@ -0,0 +1,62 @@
+other: 0.910
+graphic: 0.778
+debug: 0.735
+performance: 0.653
+device: 0.609
+semantic: 0.588
+files: 0.533
+network: 0.411
+permissions: 0.399
+PID: 0.386
+boot: 0.363
+socket: 0.346
+vnc: 0.290
+KVM: 0.091
+
+getifaddrs linked with musl libc hangs on big-endian targets
+Description of problem:
+When the following C program (borrowed from curl's `configure`) is compiled for { m68k, ppc, ppc64, s390x } (possibly others, like or1k and sparc) and linked against musl libc, it hangs inside musl when run. Copying the same binaries to real hardware results in success.
+
+```c
+#include <stdlib.h>
+#include <ifaddrs.h>
+
+int
+main (void)
+{
+
+    struct ifaddrs *ifa = 0;
+    int error;
+
+    error = getifaddrs(&ifa);
+    if (error || !ifa)
+        exit(1);
+    else
+        exit(0);
+
+    return 0;
+}
+```
+Steps to reproduce:
+1. Compile the above program and link it with musl libc (pre-built toolchains are available [here](https://musl.cc/))
+2. Run the appropriate `qemu-*` (e.g. `qemu-m68k ./test` or `qemu-ppc ./test`)
+3. Observe that the process hangs.
+Additional information:
+This has come up elsewhere:
+
+* https://bugs.gentoo.org/914256
+* https://www.openwall.com/lists/musl/2018/05/30/4
+* Likely affects or1k but I can't test that at the moment (need to debug an unrelated issue with that toolchain)
+* Likely affects sparc but that port/toolchain is also a WIP
+
+Here are some static sample binaries for the above program:
+
+* https://temp.zv.io/qemu-bug.tar.xz (no guarantees of continued existence months or years later)
+
+GitLab labels seem to be missing:
+
+* ~"kind::Bug"
+* ~"linux-user"
+* ~"target: ppc"
+* ~"target: m68k"
+* ~"target: s390x"