TCG: 0.879 architecture: 0.868 mistranslation: 0.824 ppc: 0.802 device: 0.784 peripherals: 0.705 files: 0.699 arm: 0.636 user-level: 0.632 permissions: 0.625 network: 0.621 PID: 0.618 debug: 0.601 graphic: 0.592 kernel: 0.592 socket: 0.586 vnc: 0.569 performance: 0.567 x86: 0.512 semantic: 0.511 i386: 0.476 boot: 0.470 register: 0.466 risc-v: 0.446 VMM: 0.443 hypervisor: 0.364 virtual: 0.341 KVM: 0.245 assembly: 0.213 -------------------- arm: 0.981 TCG: 0.892 debug: 0.146 performance: 0.058 virtual: 0.039 hypervisor: 0.037 files: 0.032 kernel: 0.014 semantic: 0.013 user-level: 0.010 architecture: 0.008 register: 0.007 PID: 0.007 assembly: 0.006 network: 0.006 mistranslation: 0.003 device: 0.003 boot: 0.003 socket: 0.002 peripherals: 0.002 graphic: 0.002 vnc: 0.001 VMM: 0.001 risc-v: 0.001 permissions: 0.001 ppc: 0.000 x86: 0.000 KVM: 0.000 i386: 0.000 cpu_exec: Assertion !have_mmap_lock() failed Hi, I have isolated a testcase from the GCC testsuite (actually gfortran, test proc_ptr_51.f90) which produces tons of: qemu-arm: /home/christophe.lyon/src/qemu/accel/tcg/cpu-exec.c:701: cpu_exec: Assertion `!have_mmap_lock()' failed. including with master qemu as of today. I'm attaching a tarball containing: qemu-assert: cmd lib proc_ptr_51.exe qemu-assert/lib: ld-linux-armhf.so.3 libc.so.6 libgcc_s.so.1 libgfortran.so.5 libm.so.6 where cmd is the basic command used to launch the test & reproduce the failure. Note that the test or the generated may actually be buggy: I have reported failures on native aarch64 and arm machines. Yet, qemu should not fail with a loop of asserts. What version of qemu where you running? My HEAD is failing in a different way. It's fairly recent: qemu-arm version 4.0.50 (v4.0.0-1215-ga578cdf-dirty) Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers commit a578cdfbdd8f9beff5ced52b7826ddb1669abbbf Merge: 19735c8 43b3952 Author: Peter Maydell