qemu-arm (user mode) segfaults in uclibc-ng chroot after upgrade to 2.11.x I use a qemu-user chroot + binfmt to build software targetting a raspberry pi. After upgrading from qemu-2.10.1 to 2.11.1 (Gentoo host), I noticed that on my uclibc-ng chroot qemu-arm will segfault when running python and importing the portage module. I have bisected qemu down to this commit: https://github.com/qemu/qemu/commit/18e80c55bb6ec17c05ec0ba717ec83933c2bfc07 If I recompile and change MAX_RESERVED_VA (from the above commit) back to 0x77000000 the problem goes away. NB I have no idea what that does, I just thought I'd see. Other arm chroots (glibc, musl) do not segfault with qemu-2.11, only the uclibc-ng one. Not sure why. The following backtrace was generated from running qemu-arm in gdb and recreating the segfault: (gdb) where #0 0x0000000060726046 in static_code_gen_buffer () #1 0x0000000060048789 in cpu_tb_exec (cpu=0x6278e310, itb=0x60725f80 ) at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:167 #2 0x000000006004937f in cpu_loop_exec_tb (cpu=0x6278e310, tb=0x60725f80 , last_tb=0x7fffffffd138, tb_exit=0x7fffffffd130) at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:627 #3 0x0000000060049600 in cpu_exec (cpu=0x6278e310) at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:736 #4 0x00000000600511c3 in cpu_loop (env=0x627965b0) at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/linux-user/main.c:585 #5 0x00000000600534eb in main (argc=4, argv=0x7fffffffd9b8, envp=0x7fffffffd9e0) at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/linux-user/main.c:4882 (gdb) info reg rax 0x627965b0 1652123056 rbx 0x62717870 1651603568 rcx 0x606da000 1617797120 rdx 0x60726000 1618108416 rsi 0x60726000 1618108416 rdi 0x627965b0 1652123056 rbp 0x7fffffffd0c0 0x7fffffffd0c0 rsp 0x7fffffffd080 0x7fffffffd080 r8 0x0 0 r9 0x2 2 r10 0x0 0 r11 0x629280a0 1653768352 r12 0x60260e40 1613106752 r13 0x0 0 r14 0x606a5018 1617580056 r15 0x0 0 rip 0x60048789 0x60048789 eflags 0x10282 [ SF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) Could you try with current head-of-git (the 2.12 rc4)? We adjusted our logic for setting up the initial reserved space since 2.11 -- it may well not fix this bug, but maybe we'll be lucky... Unfortunately, no dice 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. [Expired for QEMU because there has been no activity for 60 days.]