diff options
Diffstat (limited to 'results/classifier/118/unknown/1701798')
| -rw-r--r-- | results/classifier/118/unknown/1701798 | 453 |
1 files changed, 453 insertions, 0 deletions
diff --git a/results/classifier/118/unknown/1701798 b/results/classifier/118/unknown/1701798 new file mode 100644 index 000000000..c15ff18bc --- /dev/null +++ b/results/classifier/118/unknown/1701798 @@ -0,0 +1,453 @@ +architecture: 0.857 +permissions: 0.854 +performance: 0.843 +register: 0.831 +device: 0.831 +files: 0.827 +peripherals: 0.809 +virtual: 0.808 +user-level: 0.808 +arm: 0.796 +assembly: 0.793 +graphic: 0.793 +network: 0.792 +debug: 0.788 +socket: 0.781 +KVM: 0.776 +PID: 0.769 +VMM: 0.765 +boot: 0.755 +risc-v: 0.747 +vnc: 0.745 +hypervisor: 0.742 +semantic: 0.739 +kernel: 0.735 +i386: 0.733 +mistranslation: 0.715 +ppc: 0.703 +TCG: 0.699 +x86: 0.670 + +dynamically linked binaries crash for big-endian targets + +On the targets + hppa + m68k + mips + mips64 + powerpc + powerpc64 + s390x + sparc64 +dynamically linked binaries crash, but statically linked binaries work. +On the targets + aarch64 + alpha + armhf + powerpc64le + sh4 +both dynamically linked and statically linked binaries work. + +How to reproduce: + +1) On Ubuntu 16.04, install the packages +g++-5-aarch64-linux-gnu +g++-5-alpha-linux-gnu +g++-5-arm-linux-gnueabihf +g++-5-hppa-linux-gnu +g++-5-m68k-linux-gnu +g++-5-mips-linux-gnu +g++-5-mips64-linux-gnuabi64 +g++-5-powerpc-linux-gnu +g++-5-powerpc64-linux-gnu +g++-5-powerpc64le-linux-gnu +g++-5-s390x-linux-gnu +g++-5-sh4-linux-gnu +g++-5-sparc64-linux-gnu + +2) Install qemu 2.9.0 from source (for m68k, use the 2.7.0-m68k +code from https://github.com/vivier/qemu-m68k.git): +$ ../configure --prefix=/home/bruno/inst-qemu/2.9.0 --target-list=aarch64-softmmu,alpha-softmmu,arm-softmmu,i386-softmmu,m68k-softmmu,mips-softmmu,mipsel-softmmu,mips64-softmmu,mips64el-softmmu,ppc-softmmu,ppc64-softmmu,s390x-softmmu,sh4-softmmu,sparc-softmmu,sparc64-softmmu,x86_64-softmmu,aarch64-linux-user,alpha-linux-user,arm-linux-user,hppa-linux-user,m68k-linux-user,mips-linux-user,mipsel-linux-user,mips64-linux-user,mips64el-linux-user,ppc-linux-user,ppc64-linux-user,ppc64le-linux-user,s390x-linux-user,sh4-linux-user,sparc-linux-user,sparc64-linux-user --disable-strip --disable-werror --enable-gtk --enable-vnc +$ make +$ make install + +3) Cross-compile the programs: + +$ aarch64-linux-gnu-gcc-5 -O hello.c -o hello.aarch64 +$ alpha-linux-gnu-gcc-5 -O hello.c -o hello.alpha +$ arm-linux-gnueabihf-gcc-5 -O hello.c -o hello.armhf +$ hppa-linux-gnu-gcc-5 -O hello.c -o hello.hppa +$ m68k-linux-gnu-gcc-5 -O hello.c -o hello.m68k +$ mips-linux-gnu-gcc-5 -O hello.c -o hello.mips +$ mips64-linux-gnuabi64-gcc-5 -O hello.c -o hello.mips64 +$ powerpc-linux-gnu-gcc-5 -O hello.c -o hello.powerpc +$ powerpc64-linux-gnu-gcc-5 -O hello.c -o hello.powerpc64 +$ powerpc64le-linux-gnu-gcc-5 -O hello.c -o hello.powerpc64le +$ s390x-linux-gnu-gcc-5 -O hello.c -o hello.s390x +$ sh4-linux-gnu-gcc-5 -O hello.c -o hello.sh4 +$ sparc64-linux-gnu-gcc-5 -O hello.c -o hello.sparc64 + +4) Run the programs: + +* aarch64 works: +$ QEMU_LD_PREFIX=/usr/aarch64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-aarch64 hello.aarch64 +Hello world + +* alpha works: +$ QEMU_LD_PREFIX=/usr/alpha-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-alpha hello.alpha +Hello world + +* armhf works: +$ QEMU_LD_PREFIX=/usr/arm-linux-gnueabihf ~/inst-qemu/2.9.0/bin/qemu-arm hello.armhf +Hello world + +* powerpc64le works: +$ QEMU_LD_PREFIX=/usr/powerpc64le-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-ppc64le hello.powerpc64le +Hello world + +* sh4 works: +$ QEMU_LD_PREFIX=/usr/sh4-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-sh4 hello.sh4 +Hello world + +* ===== sparc64 does not work: +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-sparc64 hello.sparc64 +Segmentation fault (core dumped) + +When I copy the file to a machine with `uname -srm` = "Linux 4.5.0-2-sparc64 sparc64", +it works: +$ ./hello.sparc64 +Hello world + +When I copy the file and its execution environment /usr/sparc64-linux-gnu to the +same machine and run the binary in a chroot environment: +# /bin/hello.sparc64 +Hello world + +* ===== mips does not work: +$ QEMU_LD_PREFIX=/usr/mips-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-mips hello.mips +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +When I copy the file to a machine with `uname -srm` = "Linux 3.16.0-4-4kc-malta mips", +it works: +$ ./hello.mips +Hello world + +When I copy the file and its execution environment /usr/mips-linux-gnu to the +same machine and run the binary in a chroot environment: +# /bin/hello.mips +Hello world + +* ===== mips64 does not work: +$ QEMU_LD_PREFIX=/usr/mips64-linux-gnuabi64 ~/inst-qemu/2.9.0/bin/qemu-mips64 hello.mips64 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +When I copy the file to a machine with `uname -srm` = "Linux 3.16.0-4-5kc-malta mips64", +it works: +$ ./hello.mips64 +Hello world + +* ===== powerpc does not work: +$ QEMU_LD_PREFIX=/usr/powerpc-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-ppc hello.powerpc +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +When I copy the file to a machine with `uname -srm` = "Linux 3.17.2-200.fc20.ppc64p7 ppc64", +it works: +$ ./hello.powerpc +Hello world + +* ===== powerpc64 does not work: +$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-ppc64 hello.powerpc64 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +When I copy the file to a machine with `uname -srm` = "Linux 3.17.2-200.fc20.ppc64p7 ppc64", +it works: +$ ./hello.powerpc64 +Hello world + +* ===== s390x does not work: +$ QEMU_LD_PREFIX=/usr/s390x-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-s390x hello.s390x +<hangs> +$ QEMU_LD_PREFIX=/usr/s390x-linux-gnu ~/inst-qemu/2.8.1/bin/qemu-s390x hello.s390x +qemu-s390x: /media/develdata/devel/build/qemu-2.8.1/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +Segmentation fault (core dumped) + +When I copy the file to a machine with `uname -srm` = "Linux 3.16.0-4-s390x s390x", +it works: +$ ./hello.s390x +Hello world + +* ===== hppa does not work: +$ QEMU_LD_PREFIX=/usr/hppa-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-hppa hello.hppa +Segmentation fault (core dumped) + +* ===== m68k does not work: +$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.9.0/bin/qemu-m68k hello.m68k +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.7.0-m68k/bin/qemu-m68k hello.m68k +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + + +The set of targets where it does not work is exactly the big-endian targets. + +I would guess that the problem comes from a missing (or an extra) BSWAP call in one of the files + include/elf.h + include/hw/elf_ops.h + linux-user/elfload.c + + +I think I hit this problem trying to use qemu-s390x-static in the s390x/ubuntu:16.04 docker image. Running qemu-s390x-static 2.9.0 on binaries in that image (e.g. /bin/echo) results in a hang. + +I've noticed that doing the same in a s390x/debian:jessie image does NOT have the same problem. No hang. Looks like the binaries are built for different kernel versions, could that be why? + +$ file ubuntu16.04/bin/echo +ubuntu16.04/bin/echo: ELF 64-bit MSB shared object, IBM S/390, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=4befa0df07957e117e8cc44d0dd14a3df6d44619, stripped + +$ file debian/bin/echo +debian/bin/echo: ELF 64-bit MSB executable, IBM S/390, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1, for GNU/Linux 2.6.32, BuildID[sha1]=4bd45eb0ae5287ba9271a9daa9809166dd2eeab5, stripped + +The behaviour in qemu-2.10 is nearly the same as in qemu-2.9. The only difference is a different kind of crash for m68k: + +$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.9.0/bin/qemu-m68k hello.m68k +qemu: uncaught target signal 4 (Illegal instruction) - core dumped + +$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.10.0/bin/qemu-m68k hello.m68k +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + + +Can you check whether these work if you copy the QEMU and the dynamically linked target binary into a chroot (which does not have the x86 host ld.so or /etc in it) instead of using QEMU_LD_PREFIX ? There is a problem I've seen before where: + 1) QEMU when run with QEMU_LD_PREFIX or -L works by "first try in -L, then try in the host filesystem" + 2) files like /etc/ld.so.cache (and other things the dynamic linker uses) are not in the -L directory but are in the host + 3) the ld.so.cache format is not endian-agnostic + 4) glibc's dynamic linker code does not ignore a wrong-endian ld.so.cache but crashes instead + +Using a chroot instead of QEMU_LD_PREFIX will work as a test of whether this is the kind of problem you're running into. Personally I think that (4) is a glibc bug... + + +For s390x, the hang definitely still occurs using a chroot with qemu-s390x-static copied in and no QEMU_LD_PREFIX. I'm not in a good position to test other big-endian architectures though. + +I just tested with powerpc and current head-of-git QEMU and it works: + +e104462:xenial:bug-1701798$ cat hello.c +#include <stdio.h> +int main(void) { + printf("hello world\n"); + return 0; +} +e104462:xenial:bug-1701798$ powerpc-linux-gnu-gcc-5 -O hello.c -o hello.powerpc +e104462:xenial:bug-1701798$ QEMU_LD_PREFIX=/usr/powerpc-linux-gnu ~/linaro/qemu-from-laptop/qemu/build/all-linux-static/ppc-linux-user/qemu-ppc ./hello.powerpc +hello world + +Similarly mips, sparc64, powerpc64, hppa, mips64 are fine. + +m68k is known to be not working for real m68k currently (it's mostly a coldfire target), so not surprising that that doesn't work. + +s390x still crashes: +qemu-s390x: /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/translate-all.c:189: tb_lock: Assertion `!have_tb_lock' failed. + +So either we've fixed a bug here, or the problem is in your environment. + +For s390, it looks like the guest is trying to use an insn we don't implement: +#0 0x0000000060215018 in raise () +#1 0x000000006021573a in abort () +#2 0x0000000060079a96 in op_risbg (s=0x7fffffffda10, o=0x7fffffffd950) + at /home/petmay01/linaro/qemu-from-laptop/qemu/target/s390x/translate.c:3450 +#3 0x0000000060082c8b in translate_one (env=0x627f0350, s=0x7fffffffda10) + at /home/petmay01/linaro/qemu-from-laptop/qemu/target/s390x/translate.c:5824 +#4 0x0000000060082f3f in gen_intermediate_code (cs=0x627e80b0, + tb=0x60794d40 <static_code_gen_buffer+56064>) + at /home/petmay01/linaro/qemu-from-laptop/qemu/target/s390x/translate.c:5925 +#5 0x00000000600369aa in tb_gen_code (cpu=0x627e80b0, pc=274886359240, + cs_base=0, flags=3, cflags=0) + at /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/translate-all.c:1286 +#6 0x00000000600343ff in tb_find (cpu=0x627e80b0, + last_tb=0x60794c00 <static_code_gen_buffer+55744>, tb_exit=0, cf_mask=0) + at /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/cpu-exec.c:402 +#7 0x0000000060034b36 in cpu_exec (cpu=0x627e80b0) + at /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/cpu-exec.c:722 +#8 0x000000006003ac78 in cpu_loop (env=0x627f0350) + at /home/petmay01/linaro/qemu-from-laptop/qemu/linux-user/main.c:3255 +---Type <return> to continue, or q <return> to quit--- +#9 0x000000006003c68c in main (argc=2, argv=0x7fffffffe458, envp=0x7fffffffe470) + at /home/petmay01/linaro/qemu-from-laptop/qemu/linux-user/main.c:4882 + +where the abort is in op_risbg() because s->fields->op2 is 0x59, which we don't handle. + +We then fail to correctly report that abort(), because linux-user has never been very good with reporting signals caused by QEMU itself -- it assumes signals including SIGABRT are due to the guest code and tries to deliver them as guest signals, usually tripping itself up in the process. We then run into the bug described in https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg01506.html which is why we get the have_tb_lock assertion. + + + +This patch fixes the s390 issue: +https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg01103.html + +which is the only part of this (ignoring m68k) that I could reproduce. Bruno: can you still reproduce any of the other problems with a new QEMU? + + +> can you still reproduce any of the other problems with a new QEMU? + +On the same system (Ubuntu 16.04 x86_64, not a chroot environment), I still observe the same symptoms with QEMU as of today than with 2.9.0 or 2.10.0: + +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-sparc64 hello.sparc64 +Segmentation fault (core dumped) +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-sparc64 hello.sparc64 +Segmentation fault (core dumped) + +$ QEMU_LD_PREFIX=/usr/mips-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-mips hello.mips +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +$ QEMU_LD_PREFIX=/usr/mips-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-mips hello.mips +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +$ QEMU_LD_PREFIX=/usr/mips64-linux-gnuabi64 ~/inst-qemu/2.9.0/bin/qemu-mips64 hello.mips64 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +$ QEMU_LD_PREFIX=/usr/mips64-linux-gnuabi64 ~/inst-qemu/2.10+-20171107/bin/qemu-mips64 hello.mips64 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +$ QEMU_LD_PREFIX=/usr/powerpc-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-ppc hello.powerpc +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +$ QEMU_LD_PREFIX=/usr/powerpc-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-ppc hello.powerpc +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-ppc64 hello.powerpc64 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-ppc64 hello.powerpc64 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +$ QEMU_LD_PREFIX=/usr/s390x-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-s390x hello.s390x +Killed +$ QEMU_LD_PREFIX=/usr/s390x-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-s390x hello.s390x +Killed + +$ QEMU_LD_PREFIX=/usr/hppa-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-hppa hello.hppa +Segmentation fault (core dumped) +$ QEMU_LD_PREFIX=/usr/hppa-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-hppa hello.hppa +Segmentation fault (core dumped) + +$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.10.0/bin/qemu-m68k hello.m68k +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.10+-20171107/bin/qemu-m68k hello.m68k +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + + +Re #4: +> 2) files like /etc/ld.so.cache (and other things the dynamic linker uses) are not in the -L directory but are in the host +> 3) the ld.so.cache format is not endian-agnostic +> 4) glibc's dynamic linker code does not ignore a wrong-endian ld.so.cache but crashes instead + +Indeed the problem is with /etc/ld.so.cache, and ONLY /etc/ld.so.cache. When I hack the do_openat function in linux-user/syscall.c, to pretend that no /etc/ld.so.cache exists, - see attached hide-ld.so.cache.diff - the dynamically-linked binaries work (except the s390x case, which you identified as a different issue): + +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-sparc64 hello.sparc64 +Hello world +$ QEMU_LD_PREFIX=/usr/mips-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-mips hello.mips +Hello world +$ QEMU_LD_PREFIX=/usr/mips64-linux-gnuabi64 ~/inst-qemu/2.10+-20171107/bin/qemu-mips64 hello.mips64 +Hello world +$ QEMU_LD_PREFIX=/usr/powerpc-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-ppc hello.powerpc +Hello world +$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-ppc64 hello.powerpc64 +Hello world +$ QEMU_LD_PREFIX=/usr/s390x-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-s390x hello.s390x +Killed +$ QEMU_LD_PREFIX=/usr/hppa-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-hppa hello.hppa +Hello world +$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.10+-20171107/bin/qemu-m68k hello.m68k +Hello world + +Hurray! This bug that has seriously limited the value of linux-user emulation is now gone for me! + +> Can you check whether these work if you copy the QEMU and the dynamically linked target binary into a chroot + +This is way too cumbersome for me: + - Need to copy my workspaces into specific file locations on the disk, + - Need to use 'chroot' command before anything else, + - Need to use a statically-linked qemu. + +> Personally I think that (4) is a glibc bug... + +Maybe, but if you can fix it in 5 to 10 lines code in qemu, I doubt it's worth reporting it to the glibc people. + +Small improvement: In my hack, I just pretended /etc/ld.so.cache is absent. Possibly it's better to map it to $QEMU_LD_PREFIX/etc/ld.so.cache . + +That patch would prevent us from picking up a legitimate ld.so.cache for the guest (in a chroot, for instance), so I don't think we should take it. (I'm also not a fan of trying to work around specific guest code issues: I'd much rather this was just fixed in ld.so where it ought to be, so I'd encourage you to report it to the glibc folks.) + +You can probably also work around this by creating an empty ld.so.cache in the QEMU_LD_PREFIX directory, though it's awkward if you wanted that to be the /usr/whatever directory. + +The underlying problem here is that the -L option is not really a very good one compared to a proper chroot -- it doesn't really present a proper guest filesystem to the guest. + + +> That patch would prevent us from picking up a legitimate ld.so.cache for the guest (in a chroot, for instance), so I don't think we should take it. +But in a chroot, QEMU_LD_PREFIX is most likely NOT set. So how about this pseudocode? + + if (strcmp (pathname, "/etc/ld.so.cache") == 0 && getenv ("QEMU_LD_PREFIX") != NULL) { + pathname = concat (getenv ("QEMU_LD_PREFIX"), pathname); + } + +That is, redirect /etc/ld.so.cache to $QEMU_LD_PREFIX/etc/ld.so.cache if and only if $QEMU_LD_PREFIX is set. + +> You can probably also work around this by creating an empty ld.so.cache in the QEMU_LD_PREFIX directory, though it's awkward if you wanted that to be the /usr/whatever directory. + +Indeed, qemu already analyzes the QEMU_LD_PREFIX, stores a cache of its contents in the static variable 'base', and uses it in the do_openat() function. + +The following provides a workaround for me that does not require any change to qemu: + +sudo mkdir -p $QEMU_LD_PREFIX/etc +sudo ln -s /nonexistent $QEMU_LD_PREFIX/etc/ld.so.cache + + +I still feel we shouldn't be working around guest code bugs in QEMU, so I'm not sure there's anything more for QEMU to do here. You should report the dynamic linker bug to glibc upstream. + + +My feeling is that glibc upstream will not want to care about cross qemu situations. I would prefer to report it to the Ubuntu cross-tools maintainers: The package libc6-<cpu>-cross contains the file /usr/<cpu>-linux-gnu/lib/libc.so.6; they could surely add the symlink for /usr/<cpu>-linux-gnu/etc/ld.so.cache as well. + +I believe this same bug affects me on Linux Mint 18.3 Sylvia which is based on Ubuntu Xenial. +The suggestion from #12 helped me. Thank you @bruno-clisp! + +Did we open a precise glibc upstream bug for this so I can go upvote it? :-) + +Workaround from #12 also worked for me. + +Tested on Buildroot with this precise setup: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/e855a262fd872171156894e9045814cb0f346dab#stack-smashing-detected + +For Google, the error message in that setup is: + +*** stack smashing detected ***: <unknown> terminated +qemu: uncaught target signal 6 (Aborted) - core dumped + +but must be the same as reported here just with a different glibc setup leading to slightly different crash. + + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +The issue seems to be fixed, even without the symlink for /usr/<cpu>-linux-gnu/etc/ld.so.cache. +For m68k: since version 2.10.0. +For s390x: since version 2.11.0. +For the other platforms, already since 2.9.0 (strange, this contradicts my original report...). + +My last comment ("The issue seems to be fixed, even without the symlink for /usr/<cpu>-linux-gnu/etc/ld.so.cache.") was incorrect. When this symlink is set, the program accesses /etc/ld.so.cache after accessing /usr/<cpu>-linux-gnu/etc/ld.so.cache. In some cases, it works, in some cases it doesn't — depending on the contents of /etc/ld.so.cache. + +The better fix is to replace /usr/<cpu>-linux-gnu/etc/ld.so.cache with an empty file: + +rm -f "/usr/<cpu>-linux-gnu/etc/ld.so.cache" +mkdir -p "/usr/<cpu>-linux-gnu/etc" +: > "/usr/<cpu>-linux-gnu/etc/ld.so.cache" + + |