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