add zero-shot results

1 files changed, 53 insertions, 0 deletions

diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2485 b/results/classifier/zero-shot-user-mode/output/instruction/2485
new file mode 100644
index 000000000..01431ab6d
--- /dev/null
+++ b/results/classifier/zero-shot-user-mode/output/instruction/2485
@@ -0,0 +1,53 @@
+instruction: 0.552
+runtime: 0.306
+syscall: 0.143
+
+
+
+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"