cpu_exec: Assertion !have_mmap_lock() failed

Bug #1832353 reported by Christophe Lyon
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QEMU
Fix Released
Undecided
Richard Henderson

Bug Description

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.

Tags: arm tcg testcase
Revision history for this message
Christophe Lyon (christophe-lyon) wrote :
Alex Bennée (ajbennee)
tags: added: arm tcg testcase
Revision history for this message
Alex Bennée (ajbennee) wrote :

What version of qemu where you running? My HEAD is failing in a different way.

Revision history for this message
Christophe Lyon (christophe-lyon) wrote :

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 <email address hidden>
Date: Mon Jun 10 16:09:19 2019 +0100

     Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20190610' into staging

     Move softmmu tlb into CPUNegativeOffsetState

configured with:
--target-list=arm-softmmu,arm-linux-user,aarch64-softmmu,aarch64-linux-user --enable-debug

Revision history for this message
Richard Henderson (rth) wrote :

Confirmed. The exact failure mode depends on debugging enabled or not.

The test case is "buggy" in the sense that it makes a call to a NULL
function pointer, and the failure happens while trying to translate
the instructions at address 0.

That said, the correct behaviour for QEMU is a SIGSEGV delivered to
the guest, not an assertion failure.

Changed in qemu:
assignee: nobody → Richard Henderson (rth)
status: New → In Progress
Revision history for this message
Peter Maydell (pmaydell) wrote :

The fix for this bug is now in master and will be in QEMU 4.1.

Changed in qemu:
status: In Progress → Won't Fix
status: Won't Fix → Fix Committed
Alex Bennée (ajbennee)
Changed in qemu:
status: Fix Committed → In Progress
Revision history for this message
Alex Bennée (ajbennee) wrote :
Richard Henderson (rth)
Changed in qemu:
status: In Progress → Fix Committed
Revision history for this message
Thomas Huth (th-huth) wrote :
Changed in qemu:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.