[Qemu-devel] [Bug 1765970] [NEW] qemu-arm (user mode) segfaults in uclibc-ng chroot after upgrade to 2.11.x

[diddly]

Public bug reported:

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)

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1765970

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

Status in QEMU:
  New

Bug description:
  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)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1765970/+subscriptions