3 files changed, 130 insertions, 0 deletions
diff --git a/results/classifier/108/other/922 b/results/classifier/108/other/922
new file mode 100644
index 00000000..0bb12a34
--- /dev/null
+++ b/results/classifier/108/other/922
@@ -0,0 +1,35 @@
+graphic: 0.796
+device: 0.756
+semantic: 0.572
+performance: 0.543
+permissions: 0.506
+debug: 0.486
+vnc: 0.475
+PID: 0.343
+files: 0.288
+boot: 0.282
+other: 0.180
+socket: 0.147
+network: 0.145
+KVM: 0.016
+
+QEMU 7.0.0-rc0: Random segfaults when running grep using qemu-arm-static
+Description of problem:
+I'm running ARM binaries using 32 bit qemu-arm-static on x86_64 host. Sometimes when running grep via qemu, I get a random segmentation fault. Sometimes it happens faster, sometimes it takes several thousand iterations, but sooner or later it happens and really annoying.
+
+This problem is also reproduced on 6.2, 5.2 and 5.1 releases, and NOT reproduced on 5.0
+
+I wrote small test to demonstrate this bug.
+Steps to reproduce:
+1. Download the test environment: [qemu-test-segfault.tar.bz2](/uploads/8f52617d46ba1e5bf29fc273cd07131d/qemu-test-segfault.tar.bz2)
+2. `$ make # To build the docker container`
+3. `$ make shell # To run ARM bash`
+4. Inside a container, run `while true; do /qemu /bin/grep -E f text > /dev/null; [ $? -ne 0 ] && break; done`. After a while you will get segfault:
+```
+[root@0d81b08f032b /]# /qemu --version
+qemu-arm version 6.2.90
+Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
+[root@0d81b08f032b /]# while true; do /qemu /bin/grep -E f text > /dev/null; [ $? -ne 0 ] && break; done
+Segmentation fault (core dumped)
+[root@0d81b08f032b /]#
+```
diff --git a/results/classifier/108/other/922076 b/results/classifier/108/other/922076
new file mode 100644
index 00000000..0897d8e7
--- /dev/null
+++ b/results/classifier/108/other/922076
@@ -0,0 +1,66 @@
+graphic: 0.873
+PID: 0.858
+device: 0.846
+performance: 0.842
+files: 0.830
+other: 0.823
+permissions: 0.820
+boot: 0.810
+debug: 0.800
+vnc: 0.756
+network: 0.746
+semantic: 0.728
+socket: 0.706
+KVM: 0.681
+
+doesn't clear screen on boot
+
+When I start Linux in Qemu via "qemu -kernel /vmlinuz ...", opens Qemu window, it shows message "Starting Seabios (version 0.5.1-2010...)", and then Linux writes messages like "Loading, please wait..." on top of previous message!
+
+For example, I can see "Loading, please wait...on 0.5.1-2010...)"
+
+So, Qemu doesn't clean screan before booting OS.
+
+Moreover, when I start Linux via "qemu /disk-image", Qemu shows "Starting Seabios (version 0.5.1-2010...)", then switches to graphical mode, shows GRUB, then switches back to text mode and shows "Starting Seabios" again! And again Linux prints messages on top of Seabios messages, and we see a mix of symbols on screen.
+
+Also, I found another bug! I am learning now to write kernels. And I see that operator "*(char *)0xb8000 = 0" in C code of kernel doesn't clean first charaster of screen in Qemu in "-curses" mode! If I want to real clean this charaster, I must type "*(char *)0xb8000 = ' '".
+
+I attach a kernel (x86, multiboot) with this bug. Just type "make" (you need gcc) and "qemu -curses -kernel kernel". You will see that screen is not cleared, but kernel tries to clean it. If you change 0 to ' ', all will work!
+
+
+
+UPDATE: The second bug (which is started with "Also, I found another bug! I am learning...") is fixed in 1.4.0
+
+About the first bug: screen clears on real hardware, so it is really bug. Also, it is reproducible with Qemu 1.4.0 and Qemu 5e3a0f418c4d57399778cee0b55aebfb663b6425.
+
+Does this problem still exist with the latest version of QEMU? Which interface type are you using (SDL, gtk, ...)? Can you please provide your full command line and build options?
+
+The bug still exists in qemu 2.7 (version present in my debian stretch).
+I was not able reproduce the bug with booting kernel directly with 2.7 (-kernel ...), but booting disk image causes the bug.
+
+So, I have debian gnu/linux stretch amd64. debian package qemu-system-x86 1:2.7+dfsg-3+b1. I run my host system in qemu (i. e. I run in qemu same system that running on the host) using well known "-snapshot -drive file=/dev/sda" trick. Precise command line is:
+
+kdesudo -c "exec qemu-system-x86_64 -m 1024M -enable-kvm -daemonize -snapshot -drive file=/dev/sda,cache=none,format=raw"
+
+Qemu appears and I see usual "SeaBIOS (version 1.9.3-20161025_171302-gandalf)" as you can see at screenshot Screenshot_20161216_005817.png .
+
+Then qemu switches to grub.
+
+And then qemu switches to text mode back. And fsck prints to console: "/dev/sda2: recovering journal", but this words appears on top of that SeaBIOS self-adver., so we have the following words mixture:
+
+/dev/sda2: recovering journal25_171302-gandalf)
+
+I use sdl. I don't know build option, this is qemu from debian package
+
+This is Screenshot_20161216_005859.png , screenshot with grub
+
+And this is Screenshot_20161216_005917.png . Here (after grub) we see "recovering journal" on top of seabios string
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/87
+
+
diff --git a/results/classifier/108/other/922355 b/results/classifier/108/other/922355
new file mode 100644
index 00000000..5c0488c2
--- /dev/null
+++ b/results/classifier/108/other/922355
@@ -0,0 +1,29 @@
+KVM: 0.881
+device: 0.810
+socket: 0.803
+vnc: 0.772
+graphic: 0.708
+network: 0.694
+PID: 0.677
+performance: 0.527
+semantic: 0.487
+debug: 0.365
+permissions: 0.340
+boot: 0.298
+files: 0.291
+other: 0.264
+
+qemu crashes when invoked on Pandaboard
+
+root@omap:~# uname -a
+Linux omap 3.1.6-x6 #1 SMP Thu Dec 22 11:17:51 UTC 2011 armv7l armv7l
+armv7l GNU/Linux
+
+root@omap:~# qemu
+Could not initialize KVM, will disable KVM support
+/build/buildd/qemu-kvm-0.14.1+noroms/tcg/arm/tcg-target.c:848: tcg fatal error
+
+QEMU 0.14 is pretty much outdated nowadays ... Can you still reproduce this problem with the latest version of QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+