summary refs log tree commit diff stats
path: root/results/scraper/launchpad/1832353
blob: 82882a6aad348b6a54545e3ddb8d7eabea17e5bd (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
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 <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

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.

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


See series: https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg02189.html

https://git.qemu.org/?p=qemu.git;a=commitdiff;h=52ba13f042714c4086416