qemu-arm (user mode) segfaults in uclibc-ng chroot after upgrade to 2.11.x

[diddly]

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 <static_code_gen_buffer+314624>)
    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 <static_code_gen_buffer+314624>, 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 <cpu_tb_exec+266>
eflags 0x10282 [ SF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb)

[Peter Maydell (pmaydell)]

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

[diddly (dflogeras2)]

Unfortunately, no dice

[Thomas Huth (th-huth)]

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.

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]