[Qemu-devel] [Bug 1727737] Re: qemu-arm stalls on a GCC sanitizer test since qemu-2.7

[Peter Maydell]

Thanks. With that extra library, if I run with QEMU_STRACE=1 the
following looks very suspicious:

28865 getpid() = 28865
28865 mmap2(NULL,2101248,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 
0x43234000
28865 mprotect(0x43234000,4096,PROT_NONE) = 0
28865 rt_sigprocmask(SIG_BLOCK,0x40e077bc,0x40e0783c) = 0
28865 
clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_UNTRACED,child_stack=0x43434ff8,parent_tidptr=0x00000000,tl
s=0x00000000,child_tidptr=0x00000000) = -1 errno=22 (Invalid argument)
28865 rt_sigprocmask(SIG_SETMASK,0x40e0783c,NULL) = 0
28865 getpid() = 28865
28865 sched_yield(1082131140,0,0,0,1084256812,1084256808) = 0
28865 sched_yield(0,0,0,0,1084256812,1084256808) = 0
28865 sched_yield(0,0,0,0,1084256812,1084256808) = 0
28865 sched_yield(0,0,0,0,1084256812,1084256808) = 0


It looks like the test case is (a) calling clone() with non-standard flags and 
(b) not checking whether it failed (presumably it then hangs forever waiting 
for the non-existent second thread to do something).

This has started failing because we tightened up the handling of flags
in our clone() syscall implementation: instead of blithely accepting any
combination of flags but only giving you the behaviour that glibc
pthread_create() gives, we now fail the clone() syscall if you ask for
some behaviour we can't implement with pthread_create() or fork(). In
this case you've asked for CLONE_VM|CLONE_FS|CLONE_FILES, which is very
nearly a pthread thread but you also need
CLONE_SIGHAND|CLONE_THREAD|CLONESYSVSEM. Also you ask for
CLONE_UNTRACED, which we can't support.

It's unfortunate that this tightening up of the checks means that some
programs which ask for things we can't do but don't actually care about
them will no longer run, but I think this is overall better than
behaving wrongly for guest programs which do care, since we can't tell
which is which.


** Tags added: linux-user

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

Title:
  qemu-arm stalls on a GCC sanitizer test since qemu-2.7

Status in QEMU:
  Incomplete

Bug description:
  Hi,

  I have noticed that several GCC/sanitizer tests fail with timeout when
  executed under QEMU.

  After a bit of investigation, I have noticed that this worked with
  qemu-2.7, and started failing with qemu-2.8, and still fails with
  qemu-2.10.1

  I'm attaching a tarball containing:
  alloca_instruments_all_paddings.exe : the testcase, and the needed libs:
  lib/librt.so.1
  lib/libdl.so.2
  lib/ld-linux-armhf.so.3
  lib/libasan.so.5
  lib/libc.so.6
  lib/libgcc_s.so.1
  lib/libpthread.so.0
  lib/libm.so.6

  To reproduce the problem:
  $ qemu-arm -cpu any -R 0 -L $PWD $PWD/alloca_instruments_all_paddings.exe
  returns in less than a second with qemu-2.7, and never with qemu-2.8

  Using -d in_asm suggests that the program "almost" completes and qemu seems 
to stall on:
  0x40b6eb44: e08f4004 add r4, pc, r4

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