6 files changed, 414 insertions, 0 deletions
diff --git a/results/classifier/118/none/128 b/results/classifier/118/none/128
new file mode 100644
index 00000000..913e00c4
--- /dev/null
+++ b/results/classifier/118/none/128
@@ -0,0 +1,31 @@
+arm: 0.787
+mistranslation: 0.686
+graphic: 0.673
+files: 0.670
+device: 0.645
+architecture: 0.629
+ppc: 0.623
+performance: 0.614
+VMM: 0.605
+register: 0.572
+vnc: 0.516
+network: 0.499
+PID: 0.489
+semantic: 0.483
+kernel: 0.457
+debug: 0.453
+TCG: 0.450
+socket: 0.448
+risc-v: 0.325
+virtual: 0.322
+boot: 0.320
+KVM: 0.309
+i386: 0.296
+assembly: 0.270
+permissions: 0.221
+user-level: 0.206
+peripherals: 0.175
+x86: 0.166
+hypervisor: 0.087
+
+man page is missing suboptions for "-display"
diff --git a/results/classifier/118/none/1284090 b/results/classifier/118/none/1284090
new file mode 100644
index 00000000..b5940239
--- /dev/null
+++ b/results/classifier/118/none/1284090
@@ -0,0 +1,44 @@
+device: 0.758
+graphic: 0.738
+vnc: 0.675
+semantic: 0.646
+register: 0.642
+socket: 0.609
+risc-v: 0.602
+network: 0.602
+mistranslation: 0.601
+i386: 0.592
+performance: 0.581
+PID: 0.575
+files: 0.574
+architecture: 0.561
+ppc: 0.548
+VMM: 0.535
+permissions: 0.522
+x86: 0.496
+TCG: 0.454
+peripherals: 0.434
+assembly: 0.422
+boot: 0.420
+arm: 0.403
+kernel: 0.399
+user-level: 0.388
+hypervisor: 0.372
+KVM: 0.362
+debug: 0.348
+virtual: 0.319
+
+RFE: QMP: report error reason in BLOCK_IO_ERROR message
+
+when a disk drive is configured with the error policy enospc for write errors, the monitoring client needs a way to distinguish
+betwwen generic I/O error and the I/O error for space exausted.
+
+The JSON QMP protocol lacks this information: the BLOCK_IO_ERROR message does not provide a reason or code for the error verified, so the monitoring client cannot distinguish the source of the errors.
+
+verified against git 105a060188dc6fdd4551571a966514d1a5f6815a
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/none/1287 b/results/classifier/118/none/1287
new file mode 100644
index 00000000..63c44bca
--- /dev/null
+++ b/results/classifier/118/none/1287
@@ -0,0 +1,40 @@
+device: 0.799
+graphic: 0.686
+performance: 0.605
+network: 0.457
+permissions: 0.452
+debug: 0.440
+semantic: 0.423
+register: 0.407
+boot: 0.354
+i386: 0.349
+mistranslation: 0.329
+architecture: 0.301
+arm: 0.277
+socket: 0.275
+VMM: 0.271
+vnc: 0.219
+x86: 0.217
+PID: 0.212
+ppc: 0.172
+TCG: 0.158
+peripherals: 0.151
+risc-v: 0.138
+virtual: 0.136
+kernel: 0.130
+assembly: 0.109
+user-level: 0.088
+files: 0.066
+KVM: 0.044
+hypervisor: 0.034
+
+qemu-img info foo.qcow2 tries to get write lock
+Description of problem:
+When trying to run qemu-img info on an image which is used by QEMU qemu-img tries to acquire a write lock. Ideally this would not attempt to acquire a write lock and let qemu-img info succeed.
+```
+[jelle@t14s][/tmp]%qemu-img info /var/tmp/cockpit-qr_j3e_m.qcow2
+qemu-img: Could not open '/var/tmp/cockpit-qr_j3e_m.qcow2': Failed to get shared "write" lock
+Is another process using the image [/var/tmp/cockpit-qr_j3e_m.qcow2]?
+```
+Steps to reproduce:
+1. Run qemu-img on an image used by a QEMU process.
diff --git a/results/classifier/118/none/1288620 b/results/classifier/118/none/1288620
new file mode 100644
index 00000000..9e2dee70
--- /dev/null
+++ b/results/classifier/118/none/1288620
@@ -0,0 +1,196 @@
+register: 0.674
+semantic: 0.642
+user-level: 0.632
+virtual: 0.594
+hypervisor: 0.579
+permissions: 0.577
+peripherals: 0.563
+debug: 0.546
+risc-v: 0.537
+mistranslation: 0.536
+graphic: 0.530
+PID: 0.530
+network: 0.527
+vnc: 0.520
+TCG: 0.520
+VMM: 0.499
+x86: 0.479
+arm: 0.477
+assembly: 0.466
+device: 0.446
+KVM: 0.435
+files: 0.432
+performance: 0.430
+architecture: 0.404
+ppc: 0.392
+socket: 0.353
+boot: 0.332
+kernel: 0.324
+i386: 0.214
+
+memory leak with config file
+
+I have a Windows 7 SP1 Professional 64-bit installation on a QCOW2 image with compat=1.1, which I launch via
+
+qemu-system-x86_64 -drive file=windows_base_HDD.img,index=0,media=disk -enable-kvm -m 512M -vga std -net nic,vlan=0 -net user,vlan=0
+
+As soon as I start using the network in any application — for example, visiting www.google.com in Internet Explorer — QEMU starts gobbling memory until the (host) kernel kills it because of an OOM condition.  If I run the QEMU with the same options, but with model=e1000 option set for the NIC (i.e. -net -nic,vlan=0,model=e1000), I can use the network from the guest OS without any noticeable effect on QEMU's memory consumption.
+
+I do not have this problem when running QEMU with the exact same options (as above, without model=e1000) but with a Debian wheezy installation (on a QCOW image of the same format).  My host system in Ubuntu 13.10 x86_64, kernel image 3.11.0-17-generic, but with the QEMU packages from trusty (the codename for the next release):
+Output of `dpkg -l \*qemu\* | grep '^ii'`:
+ii  ipxe-qemu                             1.0.0+git-20130710.936134e-0ubuntu1        all          Virtual package to support use of kvm-ipxe with qemu
+ii  qemu-keymaps                          1.7.0+dfsg-3ubuntu2                        all          QEMU keyboard maps
+ii  qemu-system-common                    1.7.0+dfsg-3ubuntu2                        amd64        QEMU full system emulation binaries (common files)
+ii  qemu-system-x86                       1.7.0+dfsg-3ubuntu2                        amd64        QEMU full system emulation binaries (x86)
+ii  qemu-utils                            1.7.0+dfsg-3ubuntu2                        amd64        QEMU utilities
+
+(If necessary, I can try to reproduce this with QEMU built from the upstream source or the latest source from version control.)
+
+Please try to reproduce this with a debug built (configure --enable-debug) from latest QEMU. If it shows the same memory leak, you can try to find the cause of this leak with valgrind:
+
+valgrind --leak-check=full qemu-system-x86_64 -drive file=windows_base_HDD.img,index=0,media=disk -enable-kvm -m 512M -vga std -net nic,vlan=0 -net user,vlan=0 2>&1 | tee valgrind.log
+
+As soon as you terminate the running qemu process, valgrind will write a protocol of all allocated memory. Leaks can usually be found quite easily in this protocol: after a long run, the leak will dominate any other memory allocation. If your executable still contains the full debug information, you will also see the exact line of source code which allocates repeatedly memory.
+ 
+Please note that valgrind slows down your process by a factor of 10 to 20, so it takes some time to run Windows.
+
+If valgrind does not work (which sometimes happens), you can attach a debugger (gdb) to the running qemu process and try to detect the buggy memory allocation by setting breakpoints on the memory allocator functions (malloc or g_malloc, g_malloc0, g_new, g_new0).
+
+
+I can not reproduce this even with the Ubuntu package after rebooting after a kernel update.  I will try again with the previous kernel image to confirm this is the relevant variable.  Is it possible that the behaviour I described in the initial report is/was caused by code in the KVM module?
+
+Even after rebooting with the kernel I was using when I had the problem behaviour in QEMU, I can not reproduce the issue.  It certainly was not a one-off, because QEMU was gobbling memory consistently on my system, in consecutive sessions.
+
+I have been able to consistently reproduce the bug again, and have run QEMU with Valgrind until OOM.  It is unrelated to networking; it is caused by loading a config file.
+
+I ran QEMU from Git commit 7f6613cedc59fa849105668ae971dc31004bca1c under valgrind via...
+
+valgrind qemu-system-x86_64 -readconfig windows8_throwaway_VM.conf -m 1G -vga std 2>&1 | tee valgrind.log
+
+...where the contents of windows8_throwaway_VM.conf is...
+
+[drive]
+  file = "windows8_throwaway_HDD.img"
+  index = "0"
+  media = "disk"
+  if = "virtio"
+
+[net]
+  type = "nic"
+  vlan = "0"
+  model = "virtio"
+
+[net]
+  type = "user"
+  vlan = "0"
+
+[rtc]
+  base = "localtime"
+
+[machine]
+  accel = "kvm"
+
+(I will attach the file in a separate comment, because launchpad appears to only allow at most one attachment per comment.)
+
+It does not seem to matter whether VirtIO is used, as I have had this problem when not using any VirtIO devices, but the Windows guest I had on-hand was already using it.
+
+If I invoke QEMU with the equivalent settings all via the command line, it does not gobble memory (again, regardless of VirtIO).
+
+qemu-system-x86_64 -drive file=windows8_throwaway_HDD.img,index=0,media=disk,if=virtio -enable-kvm -m 1G -vga std -net nic,vlan=0,model=virtio -net user,vlan=0 -rtc localtime
+
+Attaching config file mentioned in previous comment.
+
+On Sat, Mar 29, 2014 at 03:02:23AM -0000, Aidan Gauland wrote:
+> I have been able to consistently reproduce the bug again, and have run
+> QEMU with Valgrind until OOM.  It is unrelated to networking; it is
+> caused by loading a config file.
+> 
+> I ran QEMU from Git commit 7f6613cedc59fa849105668ae971dc31004bca1c
+> under valgrind via...
+> 
+> valgrind qemu-system-x86_64 -readconfig windows8_throwaway_VM.conf -m 1G
+> -vga std 2>&1 | tee valgrind.log
+> 
+> ...where the contents of windows8_throwaway_VM.conf is...
+> 
+> [drive]
+>   file = "windows8_throwaway_HDD.img"
+>   index = "0"
+>   media = "disk"
+>   if = "virtio"
+> 
+> [net]
+>   type = "nic"
+>   vlan = "0"
+>   model = "virtio"
+> 
+> [net]
+>   type = "user"
+>   vlan = "0"
+> 
+> [rtc]
+>   base = "localtime"
+> 
+> [machine]
+>   accel = "kvm"
+> 
+> (I will attach the file in a separate comment, because launchpad appears
+> to only allow at most one attachment per comment.)
+> 
+> It does not seem to matter whether VirtIO is used, as I have had this
+> problem when not using any VirtIO devices, but the Windows guest I had
+> on-hand was already using it.
+> 
+> If I invoke QEMU with the equivalent settings all via the command line,
+> it does not gobble memory (again, regardless of VirtIO).
+> 
+> qemu-system-x86_64 -drive
+> file=windows8_throwaway_HDD.img,index=0,media=disk,if=virtio -enable-kvm
+> -m 1G -vga std -net nic,vlan=0,model=virtio -net user,vlan=0 -rtc
+> localtime
+
+So this is a problem that only happens under Valgrind?  Perhaps this is
+a valgrind bug.
+
+Stefan
+
+
+On Wed, 23 Apr 2014 13:10:39 -0000, Stefan Hajnoczi wrote:
+> So this is a problem that only happens under Valgrind?  Perhaps this 
+> is
+> a valgrind bug.
+
+No, it happens outside of Valgrind as well.  It only happens when QEMU 
+is told to read a config file (with -readconfig).
+
+
+
+On Wed, Apr 23, 2014 at 08:18:21PM -0000, Aidan Gauland wrote:
+> On Wed, 23 Apr 2014 13:10:39 -0000, Stefan Hajnoczi wrote:
+> > So this is a problem that only happens under Valgrind?  Perhaps this 
+> > is
+> > a valgrind bug.
+> 
+> No, it happens outside of Valgrind as well.  It only happens when QEMU 
+> is told to read a config file (with -readconfig).
+
+Weird, I tried yesterday and couldn't reproduce it against
+qemu.git/master (2d03b49c3f225994c4b0b46146437d8c887d6774) with your
+config file.
+
+I wonder if your guest is repeatedly doing something that causes QEMU to
+leak memory.  My guest was Red Hat Enterprise Linux 6.4.
+
+Does it happen if you provide a non-bootable disk image so the guest is
+stuck at the BIOS screen?  Use dd if=/dev/zero of=test.img bs=1M
+count=1024 to create an empty 1 GB raw file.
+
+Stefan
+
+
+It does seem to be related to the guest, because with a dummy (non-bootable, garbage data) disk image, the rapid memory leak does not occur.
+
+Can you still reproduce this issue with the latest version of QEMU (currently version 2.9)?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/none/1289 b/results/classifier/118/none/1289
new file mode 100644
index 00000000..326f4f2a
--- /dev/null
+++ b/results/classifier/118/none/1289
@@ -0,0 +1,31 @@
+register: 0.714
+performance: 0.600
+device: 0.581
+risc-v: 0.579
+mistranslation: 0.577
+semantic: 0.496
+vnc: 0.486
+VMM: 0.469
+ppc: 0.440
+TCG: 0.384
+arm: 0.363
+boot: 0.358
+peripherals: 0.352
+network: 0.325
+KVM: 0.311
+PID: 0.299
+x86: 0.295
+architecture: 0.255
+i386: 0.252
+virtual: 0.214
+graphic: 0.195
+kernel: 0.182
+debug: 0.174
+hypervisor: 0.146
+assembly: 0.129
+permissions: 0.126
+user-level: 0.081
+socket: 0.066
+files: 0.005
+
+plugin get registers
diff --git a/results/classifier/118/none/1289788 b/results/classifier/118/none/1289788
new file mode 100644
index 00000000..7d649a44
--- /dev/null
+++ b/results/classifier/118/none/1289788
@@ -0,0 +1,72 @@
+graphic: 0.408
+performance: 0.358
+mistranslation: 0.212
+device: 0.188
+PID: 0.171
+peripherals: 0.157
+files: 0.151
+socket: 0.148
+semantic: 0.148
+ppc: 0.138
+architecture: 0.133
+VMM: 0.132
+debug: 0.125
+permissions: 0.124
+register: 0.122
+boot: 0.116
+network: 0.114
+risc-v: 0.113
+arm: 0.111
+vnc: 0.105
+user-level: 0.095
+virtual: 0.093
+kernel: 0.082
+hypervisor: 0.081
+i386: 0.076
+TCG: 0.068
+assembly: 0.054
+KVM: 0.049
+x86: 0.026
+
+MIDI access (not only adlib) hangs WinNT on QEMU 1.7.x
+
+Windows NT 4.0 and 2000 (including the latest git release), when enabling adlib (with sb16 already enabled) or the built-in synth of the es1370, hang on QEMU 1.7.x (also with 1.7.50) when they try to play MIDI files (like canyon.mid, etc). I have already tried bisecting but seems that this bug has been introduced sometime in 1.7.0's development time.
+
+Is this problem still reproducible with the latest version of QEMU?
+
+
+On Mar 6, 2017, at 5:45 AM, <email address hidden> wrote:
+
+> 
+> Is this problem still reproducible with the latest version of QEMU?
+> 
+> ** Changed in: qemu
+>       Status: New => Incomplete
+> 
+> -- 
+> You received this bug notification because you are a member of qemu-
+> devel-ml, which is subscribed to QEMU.
+> https://bugs.launchpad.net/bugs/1289788
+> 
+> Title:
+>  MIDI access (not only adlib) hangs WinNT on QEMU 1.7.x
+> 
+> Status in QEMU:
+>  Incomplete
+> 
+> Bug description:
+>  Windows NT 4.0 and 2000 (including the latest git release), when enabling adlib (with sb16 already enabled) or the built-in synth of the es1370, hang on QEMU 1.7.x (also with 1.7.50) when they try to play MIDI files (like canyon.mid, etc). I have already tried bisecting but seems that this bug has been introduced sometime in 1.7.0's development time.
+>  Screenshot attached: http://goput.it/ig2l.png
+> 
+>  OS Used: Windows 7 x64 Ultimate SP1
+>  command-line used: qemu-system-i386w.exe -L pc-bios -m 64 -cpu pentium -drive file=vbent40.img,if=floppy,id=fda -drive file=vhd.vhd,if=ide,media=disk,bus=0,unit=0,id=harddisk0 -drive file=E:,if=ide,media=cdrom,bus=1,unit=0,id=cdrom -net nic,model=pcnet -net user -vga std -device ES1370 -boot menu=on -monitor telnet:127.0.0.1:4444,server,nowait
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1289788/+subscriptions
+
+A midi file played very will using SB16. It didn't work at all with adlib, and it played poorly in es1370. I used Windows 2000 as the guest. There were no hangs. 
+
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+