I suspect this happens when the sanitizer library calls StopTheWorld() (in libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc in GCC sources).
It does: uptr tracer_pid = internal_clone( TracerThread, tracer_stack.Bottom(), CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_UNTRACED, &tracer_thread_argument, nullptr /* parent_tidptr */, nullptr /* newtls */, nullptr /* child_tidptr */); See: https://gcc.gnu.org/viewcvs/gcc/trunk/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc?revision=253887&view=markup#l383 The recent merge with the upstream libsanitizer means that stoptheworld is now enabled on arm as well, leading to this call to internal_clone(). This matches the comment I received on the gcc-patches list: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02215.html "LSan sets atexit handler that calls internal_clone function that's not supported in QEMU" I'm wondering why this works on aarch64? (I am also using QEMU for validations of aarch64 gcc). I mean the validations do not timeout. That being said, on aarch64 the test exits with 4 as return-code (like it did on arm with qemu-2.7) It also seems to me that the sanitizer lib is trying to handle the error (see if (internal_iserror(tracer_pid, &local_errno)) line 427). As a side note, doing $ qemu-arm -E ASAN_OPTIONS=detect_leaks=0 blah does not affect the execution, while $ env ASAN_OPTIONS=detect_leaks=0 qemu-arm blah does (my question here being: why doesn't -E do what I want?) -- 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