diff options
Diffstat (limited to 'results/classifier/zero-shot/108/other/1832353')
| -rw-r--r-- | results/classifier/zero-shot/108/other/1832353 | 72 |
1 files changed, 72 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1832353 b/results/classifier/zero-shot/108/other/1832353 new file mode 100644 index 000000000..ed8732348 --- /dev/null +++ b/results/classifier/zero-shot/108/other/1832353 @@ -0,0 +1,72 @@ +device: 0.784 +files: 0.699 +permissions: 0.625 +network: 0.621 +PID: 0.618 +debug: 0.601 +other: 0.595 +graphic: 0.592 +socket: 0.586 +vnc: 0.569 +performance: 0.567 +semantic: 0.511 +boot: 0.470 +KVM: 0.245 + +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 + |