summary refs log tree commit diff stats
path: root/results/classifier/108/other/588
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/other/58880
-rw-r--r--results/classifier/108/other/58868827
-rw-r--r--results/classifier/108/other/58869137
-rw-r--r--results/classifier/108/other/58869326
-rw-r--r--results/classifier/108/other/588731169
-rw-r--r--results/classifier/108/other/58873553
-rw-r--r--results/classifier/108/other/58874876
-rw-r--r--results/classifier/108/other/588803145
8 files changed, 613 insertions, 0 deletions
diff --git a/results/classifier/108/other/588 b/results/classifier/108/other/588
new file mode 100644
index 00000000..700b2462
--- /dev/null
+++ b/results/classifier/108/other/588
@@ -0,0 +1,80 @@
+permissions: 0.794
+other: 0.788
+graphic: 0.756
+semantic: 0.740
+debug: 0.739
+performance: 0.716
+PID: 0.699
+vnc: 0.651
+socket: 0.648
+network: 0.646
+device: 0.646
+KVM: 0.619
+boot: 0.617
+files: 0.578
+
+ppc64le: fatal: Tried to call a TRAP
+Description of problem:
+`qemu: fatal: Tried to call a TRAP` occurs while running the:
+
+`/etc/ca-certificates/update.d/jks-keystore` script which is part of the package `ca-certificates-java` that is installed as a dependency of `openjdk-11-jdk`
+
+```
+Unknown privilege violation (03)
+NIP 0000004012db12b0   LR 0000004002a4335c CTR 0000004012db1280 XER 0000000000000000 CPU#1
+MSR 9000000102806901 HID0 0000000000000000  HF 9000000002806001 iidx 6 didx 6
+TB 00000538 2314542730558
+GPR00 ffffffbffcc22660 00000040033dd940 0000004002d92f00 00000040033de9a0
+GPR04 0000000000000000 0000000000002000 0000000000000000 0000000000000000
+GPR08 0000004002df2f00 0000004002df3460 0000000000000001 0000000000000000
+GPR12 0000004012db1280 00000040033e88f0 0000004001b87410 0000000000000000
+GPR16 0000004001872000 0000004012db12a4 0000004012db12ac 0000004012db12d0
+GPR20 0000004012db12d8 00000000000003d8 0000004004014e20 00000040040151f8
+GPR24 0000004002dc39f8 00000040033df9a0 0000004004014e10 0000004004014dd0
+GPR28 0000004002df3470 0000004012db1280 0000004002df4600 00000040033dd940
+CR 24884400  [ E  G  L  L  G  G  -  -  ]             RES 00000040033de9a0
+qemu: fatal: Tried to call a TRAP
+
+NIP 0000004013342588   LR 0000004013340d84 CTR 0000004013340c8c XER 0000000000000000 CPU#1
+MSR 9000000102806901 HID0 0000000000000000  HF 9000000002806001 iidx 6 didx 6
+TB 00000539 2317026761994
+GPR00 0000000000000001 00000040033df9d0 0000004013340c00 00000000fff7ad68
+GPR04 00000000fff7ad68 000000404d235860 0000000000000105 0000000000000000
+GPR08 0000000100013f10 0000000000000000 0000000000000008 00000040033cfa60
+GPR12 000000010003cd10 00000040033e88f0 000000404d204303 00000040033dfac0
+GPR16 0000004004016000 00000000fff7ad68 00000040033dfb88 0000000100001808
+GPR20 0000004012db8b90 00000040033dfa50 0000004012db8b90 0000000044000000
+GPR24 0000004012dd9000 0000004002dd6aa0 00000040033dfad8 000000404d204b08
+GPR28 0000000000000000 0000004012db1000 0000000000000010 000000404d2047a8
+CR 48884424  [ G  L  L  L  G  G  E  G  ]             RES ffffffffffffffff
+FPR00 0000000100016f00 3ff000853ce957eb 0000000000000000 0000000000000000
+FPR04 000000000000000a 0000000000000006 000000000000000e 0000000000000000
+FPR08 0000000000000042 403a000000000000 0000000000000064 0000000000000064
+FPR12 4060000000000000 0000003000000000 0000000000000000 0000000000000060
+FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPSCR 000000008a008000
+Aborted (core dumped)
+```
+Steps to reproduce:
+1. `apt-get install -y qemu qemu-user-static`
+2. `docker run --rm --privileged multiarch/qemu-user-static --reset -p yes`
+3. `docker run -it ppc64le/ubuntu:20.04 bash`
+4. `apt-get update && apt-get install -y openjdk-11-jdk`
+Additional information:
+I actually encountered this while building https://github.com/jenkinsci/docker/blob/22f3f03e03e9902640c730cdfa896dc16a21d9d5/11/debian/bullseye/hotspot/Dockerfile
+
+Specifically running:
+```
+jlink \
+         --add-modules ALL-MODULE-PATH \
+         --no-man-pages \
+         --compress=2 \
+         --output /javaruntime
+```
+
+But when I tried to reduce this down installing openjdk from the ubuntu repository didn't work and it looks to be the same issue.
+
+This looks quite similar to https://gitlab.com/qemu-project/qemu/-/issues/319, we hit that issue as well and I've verified that s390x works now
diff --git a/results/classifier/108/other/588688 b/results/classifier/108/other/588688
new file mode 100644
index 00000000..97bc3566
--- /dev/null
+++ b/results/classifier/108/other/588688
@@ -0,0 +1,27 @@
+graphic: 0.843
+device: 0.833
+performance: 0.720
+semantic: 0.635
+socket: 0.612
+other: 0.595
+PID: 0.570
+permissions: 0.561
+network: 0.515
+files: 0.481
+boot: 0.473
+vnc: 0.467
+KVM: 0.437
+debug: 0.369
+
+Hard disk images are supporting ATAPI commands. They should fail.
+
+When using a hard disk image (qcow, qcow2, vdi, vmdk, bochs), the emulated device can be a CD-ROM and support ATAPI commands.
+
+These commands fails in real hard disks and these images are not prepared to handle optical disk formats, they should fail also.
+
+Only images able to handle that formats (dmg, raw, host) should work with ATAPI commands and CD-ROM devices.
+
+Looking through old bug tickets ... is this still an issue with the latest version of QEMU, or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/588691 b/results/classifier/108/other/588691
new file mode 100644
index 00000000..d1cb95a7
--- /dev/null
+++ b/results/classifier/108/other/588691
@@ -0,0 +1,37 @@
+performance: 0.725
+device: 0.690
+other: 0.650
+network: 0.545
+semantic: 0.539
+graphic: 0.529
+PID: 0.528
+permissions: 0.413
+boot: 0.399
+vnc: 0.332
+debug: 0.329
+files: 0.315
+socket: 0.280
+KVM: 0.123
+
+QEMU is not correctly detecting host CDs
+
+QEMU's block layer contains code for detecting and using ioctls when real CD-ROM host devices are attached.
+
+This detection is not working in some host OSes while bad implemented on anothers.
+
+E.g., in Linux host qemu -cdrom /dev/sr0 is not detecting it as a CD-ROM
+E.g., in Mac OS X host qemu asks the kernel to enumerate optical devices and the compares it to the constant string "/dev/cdrom". This is useless, that enumeration is just enough, and "/dev/cdrom" will NEVER exist in Mac OS X unless manually created by the user.
+
+The linux /dev/sr0 issue should be fixed upstream:
+
+http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=3baf720e6b920d583ce2834d05e5a4e9603a1d56
+
+Maybe it's worth a backport to stable
+
+Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+
+I use real CD-ROM disc in Mac OS and Windows guests on my Mac OS 10.12 host. I have to run QEMU in root mode using the sudo command in order to access the CD-ROM drive. So I know QEMU's support for using real optical media on Mac OS hosts does work. 
+
+OK, thanks for the confirmation, John, so seems like this bug has been fixed in the past and we can close it now.
+
diff --git a/results/classifier/108/other/588693 b/results/classifier/108/other/588693
new file mode 100644
index 00000000..651a6cab
--- /dev/null
+++ b/results/classifier/108/other/588693
@@ -0,0 +1,26 @@
+device: 0.838
+other: 0.552
+network: 0.544
+performance: 0.535
+boot: 0.501
+graphic: 0.497
+socket: 0.496
+vnc: 0.428
+semantic: 0.376
+files: 0.361
+permissions: 0.295
+PID: 0.280
+debug: 0.279
+KVM: 0.099
+
+CD-ROM devices always return a one session, one track TOC
+
+CD-ROM devices always return a one session, one track TOC, no matter if it is using ioctl's with the host or DMG images (both able of having multi track, multi session discs).
+
+(P.S.: This bug prevents BeOS boot)
+
+Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/588731 b/results/classifier/108/other/588731
new file mode 100644
index 00000000..3a70dab1
--- /dev/null
+++ b/results/classifier/108/other/588731
@@ -0,0 +1,169 @@
+other: 0.812
+semantic: 0.790
+debug: 0.747
+graphic: 0.721
+permissions: 0.703
+performance: 0.698
+device: 0.697
+PID: 0.668
+socket: 0.659
+network: 0.625
+vnc: 0.622
+boot: 0.597
+files: 0.500
+KVM: 0.468
+
+PXE boot not working
+
+/root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -net tap,vlan=0,name=tap.0 -boot n -net nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -chardev socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait -monitor chardev:monitor
+
+
+
+net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open)                                                                                               
+ [Link:up, TX:0 TXE:0 RX:0 RXE:0]                                                                                                         
+ DHCP (net0 02:5a:3b:27:00:a1)................ Connection timed out (0x4c106035)                                                            
+ No more network devices                                                                                                                    
+                                                                                                                                                                                                     
+No bootable device. 
+
+
+
+After doing a system_reset ....
+
+net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open)                                                                                               
+ [Link:up, TX:0 TXE:0 RX:0 RXE:0]                                                                                                         
+DHCP (net0 02:5a:3b:27:00:a1).... ok                                                                                                       
+net0: 10.201.1.161/255.0.0.0 gw 10.0.0.1                                                                                                   
+Booting from filename "boot.pxe"                                                                                                          
+tftp://x.x.x./boot.pxe.. ok      
+
+
+And it magaically works.
+
+using HEAD.
+
+I can't reproduce this.  I'm using:
+
+commit d9b73e47a3d596c5b33802597ec5bd91ef3348e2
+Author: Corentin Chary <email address hidden>
+Date:   Tue Jun 1 23:05:44 2010 +0200
+
+    vnc: add missing target for vnc-encodings-*.o
+
+I'm using the command:
+
+sudo x86_64-softmmu/qemu-system-x86_64 -net tap,vlan=0,name=tap.0 -boot n -net nic,vlan=0,model=e1000,name=e1000.0 -chardev socket,id=monitor,host=0.0.0.0,port=1024,telnet,server,nowait -monitor chardev:monitor
+
+The DHCP server I'm using is dnsmasq and it pxe boots as expected.  I've also confirmed that pxe boot is still functional after a system_reset.
+
+Please include information about the exact version of qemu that you are using and the DHCP server that is configured on your network.  Please also try to reproduce with the latest git.
+
+using latest git
+
+dhcp-3.0.1-58.EL4
+
+with configuration: 
+
+ host     xxxx  { filename "boot.pxe"; hardware ethernet 02:5A:3B:27:00:A1; fixed-address 10.201.1.161; }
+
+#
+## server config
+#
+server-identifier   a.b.c.d;
+server-name         "some-name";
+default-lease-time  600;
+max-lease-time      1200;
+ddns-update-style   ad-hoc;
+#log-facility        local6;
+
+allow booting;
+allow bootp;
+
+
+
+Latest GIT -> git clone http://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
+
+configured with options
+
+
+./configure --target-list=x86_64-softmmu --enable-gprof --enable-debug  --enable-linux-aio  --enable-profiler --with-kvm-trace 
+
+Install prefix    /usr/local
+BIOS directory    /usr/local/share/qemu
+binary directory  /usr/local/bin
+Manual directory  /usr/local/share/man
+ELF interp prefix /usr/gnemul/qemu-%M
+Source path       /root/qemu-test/qemu-kvm
+C compiler        gcc
+Host C compiler   gcc
+CFLAGS            -g
+QEMU_CFLAGS       -Werror -m64 -fstack-protector-all -Wold-style-definition -Wold-style-declaration -I. -I$(SRC_PATH) -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -W
+strict-prototypes -Wredundant-decls -Wall -Wundef -Wendif-labels -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing
+LDFLAGS           -Wl,--warn-common -m64 -g
+make              make
+install           install
+host CPU          x86_64
+host big endian   no
+target list       x86_64-softmmu
+tcg debug enabled yes
+Mon debug enabled yes
+gprof enabled     yes
+sparse enabled    no
+strip binaries    no
+profiler          yes
+static build      no
+-Werror enabled   yes
+SDL support       yes
+curses support    yes
+curl support      yes
+check support     no
+mingw32 support   no
+Audio drivers     oss
+Extra audio cards ac97 es1370 sb16
+Block whitelist
+Mixer emulation   no
+VNC TLS support   yes
+VNC SASL support  yes
+xen support       no
+CPU emulation     yes
+brlapi support    no
+bluez  support    no
+Documentation     yes
+NPTL support      yes
+GUEST_BASE        yes
+PIE user targets  no
+vde support       no
+IO thread         no
+Linux AIO support yes
+Install blobs     yes
+KVM support       yes
+KVM PIT support   yes
+KVM device assig. yes
+KVM trace support yes
+fdt support       no
+preadv support    yes
+fdatasync         yes
+uuid support      yes
+vhost-net support yes
+
+
+
+The same to me, but rarely it does start only from third attempt
+
+There seems to be an issue with kvm virtual network interface being connected to a in-kernel bridge implementation.
+
+When you configure networking that way the bridge port comes up when the kvm instance is started.
+
+As the time from the kvm start to entering the netboot rom is minimal and the timeout before the bridge starts forwarding on new ports is long this may cause the machine never getting an address.
+
+If you are using a bridge try setting the forwarding delay to a small value like:
+
+iface vmbridge inet static
+ bridge_ports <probably should put some network interface name here - undocumented>
+ address 10.10.10.1
+ netmask 255.255.255.0
+ post-up brctl setfd vmbridge 3
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/588735 b/results/classifier/108/other/588735
new file mode 100644
index 00000000..b62b19b1
--- /dev/null
+++ b/results/classifier/108/other/588735
@@ -0,0 +1,53 @@
+performance: 0.857
+socket: 0.856
+other: 0.820
+KVM: 0.772
+semantic: 0.718
+permissions: 0.674
+network: 0.591
+graphic: 0.589
+device: 0.575
+debug: 0.437
+PID: 0.423
+vnc: 0.264
+boot: 0.185
+files: 0.137
+
+Quit command not working
+
+Qemu strace
+
+
+
+rt_sigreturn(0x1b)                      = 56
+clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f6fddecbad0) = ? ERESTARTNOINTR (To be restarted)
+--- SIGPROF (Profiling timer expired) @ 0 (0) ---
+rt_sigreturn(0x1b)                      = 56
+
+
+started with :
+
+[root@virtual-test ~]# /root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -net tap,vlan=0,name=tap.0 -chardev socket,id=serial0,host=0.0.0.0,port=$CONSOLEPORT,telnet,server,nowait -serial chardev:serial0 -hda hda -hdb hdb -hdc hdc -hdd hdd -fda fd0 -fdb fd1 -chardev socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait -monitor chardev:monitor -net nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -M pc -m 4096
+
+when removing -m 4096, the quit command works.
+
+but I think its a combination of different args that causes the problem.
+
+I tried this exact syntax and could not reproduce.  What version of qemu are you using?
+
+how much memory do you have in the host?
+
+The host now has 8GB of memory, problem remains.
+
+
+Try
+
+ ./configure --target-list=x86_64-softmmu --enable-profiler --enable-gprof --enable-io-thread --enable-debug-tcg --enable-debug
+
+
+Without these options it magically works :)
+
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/588748 b/results/classifier/108/other/588748
new file mode 100644
index 00000000..e21210dc
--- /dev/null
+++ b/results/classifier/108/other/588748
@@ -0,0 +1,76 @@
+debug: 0.841
+device: 0.833
+socket: 0.830
+network: 0.787
+boot: 0.785
+PID: 0.751
+performance: 0.726
+graphic: 0.685
+other: 0.677
+permissions: 0.675
+semantic: 0.634
+vnc: 0.618
+files: 0.605
+KVM: 0.471
+
+QEMU fails to boot DR DOS Plus since 0.6.1
+
+The commit in r1049 (serial interrupt fix (Hampa Hug)) prevents booting Digital Research DOS Plus.
+
+
+
+This patch doesn't seem correct as the spec is pretty clear that THRE interrupt enable is set to high, then an interrupt is rased if LSR.THRE=1.  Does the following also make DOSPlus boot again:
+
+
+diff --git a/hw/serial.c b/hw/serial.c
+index 9102edb..b0ac52f 100644
+--- a/hw/serial.c
++++ b/hw/serial.c
+@@ -401,7 +401,8 @@ static void serial_ioport_write(void *opaque, uint32_t addr,
+                      s->poll_msl = 0;
+                 }
+             }
+-            if (s->lsr & UART_LSR_THRE) {
++            if (s->ier & UART_IER_THRI &&
++                s->lsr & UART_LSR_THRE) {
+                 s->thr_ipending = 1;
+                 serial_update_irq(s);
+             }
+
+
+> This patch doesn't seem correct as the spec is pretty clear that THRE interrupt enable is set to high, then an interrupt is rased if LSR.THRE=1. Does the following also make DOSPlus boot again:
+
+No it doesn't. Same as unpatched.
+
+Can you add some debugging to see what IER is being set to?
+
+Do you have any insight into why DR DOS Plus is failing?
+
+> Can you add some debugging to see what IER is being set to?
+
+With DEBUG_SERIAL defined, serial logs:
+serial: event 2
+serial: write addr=0x01 val=0x02
+serial: read addr=0x01 val=0x02
+serial: read addr=0x02 val=0x02
+serial: write addr=0x01 val=0x00
+serial: write addr=0x03 val=0x80
+serial: write addr=0x00 val=0x0c
+serial: write addr=0x01 val=0x00
+serial: write addr=0x03 val=0x03
+serial: write addr=0x04 val=0x0b
+serial: read addr=0x05 val=0x60
+serial: read addr=0x06 val=0xb0
+serial: read addr=0x00 val=0x00
+serial: write addr=0x01 val=0x0f
+serial: read addr=0x02 val=0x02
+serial: read addr=0x02 val=0x01
+(stalls here)
+
+I think the interrupt should be raised only on the rising edge of THRE.
+
+Has this bug been fixed by this commit here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=1645b8eee558ffe2389
+?
+If so, I think we could now close this bug ticket...
+
diff --git a/results/classifier/108/other/588803 b/results/classifier/108/other/588803
new file mode 100644
index 00000000..6317ac0b
--- /dev/null
+++ b/results/classifier/108/other/588803
@@ -0,0 +1,145 @@
+graphic: 0.912
+other: 0.900
+KVM: 0.895
+permissions: 0.867
+debug: 0.864
+performance: 0.863
+vnc: 0.855
+device: 0.853
+semantic: 0.852
+PID: 0.839
+socket: 0.827
+boot: 0.800
+files: 0.799
+network: 0.772
+
+Image corruption during snapshot creation/deletion
+
+Hello,
+
+The creation/deletion of snapshots sometimes crashes and corrupts the VM image and provoke a segmentation fault in "strcmp", called from "bdrv_snapshot_find".
+
+Here is a patch that temporarily fixes that (it fixes the segfault but not its reason) :
+
+--- qemu-kvm-0.12.2-old/savevm.c	2010-01-18 19:48:25.000000000 +0100
++++ qemu-kvm-0.12.2/savevm.c	2010-02-12 13:45:07.225644169 +0100
+@@ -1624,6 +1624,7 @@
+     int nb_sns, i, ret;
+ 
+     ret = -ENOENT;
++	if (!name) return ret;
+     nb_sns = bdrv_snapshot_list(bs, &sn_tab);
+     if (nb_sns < 0)
+         return ret;
+@@ -1649,6 +1650,8 @@
+     QEMUSnapshotInfo sn1, *snapshot = &sn1;
+     int ret;
+ 
++	if (!name) return 0;
++
+     QTAILQ_FOREACH(dinfo, &drives, next) {
+         bs = dinfo->bdrv;
+         if (bdrv_can_snapshot(bs) &&
+@@ -1777,6 +1780,11 @@
+     QTAILQ_FOREACH(dinfo, &drives, next) {
+         bs1 = dinfo->bdrv;
+         if (bdrv_has_snapshot(bs1)) {
++			if (!name) {
++				monitor_printf(mon, "Could not find snapshot 'NULL' on "
++								                   "device '%s'\n",
++								                   bdrv_get_device_name(bs1));
++			}
+             ret = bdrv_snapshot_goto(bs1, name);
+             if (ret < 0) {
+                 if (bs != bs1)
+@@ -1804,6 +1812,11 @@
+         }
+     }
+ 
++	if (!name) {
++		monitor_printf(mon, "VM state name is NULL\n");
++		return -EINVAL;
++	}
++
+     /* Don't even try to load empty VM states */
+     ret = bdrv_snapshot_find(bs, &sn, name);
+     if ((ret >= 0) && (sn.vm_state_size == 0))
+@@ -1840,6 +1853,11 @@
+     QTAILQ_FOREACH(dinfo, &drives, next) {
+         bs1 = dinfo->bdrv;
+         if (bdrv_has_snapshot(bs1)) {
++			if (!name) {
++				monitor_printf(mon, "Could not find snapshot 'NULL' on "
++								                   "device '%s'\n",
++								                   bdrv_get_device_name(bs1));
++			}
+             ret = bdrv_snapshot_delete(bs1, name);
+             if (ret < 0) {
+                 if (ret == -ENOTSUP)
+
+
+The patch is very simple. Some checks on the variable "name" were missing in "savevm.c".
+
+Regards,
+
+Nicolas Grandjean
+Conix Security
+
+Can you provide more information about what leads to corruption?  For instance, how are you launching the guest?
+
+# tar -zxf qemu-kvm-0.12.4.tar.gz
+# cd qemu-kvm-0.12.4/
+# ./configure --enable-debug && make && sudo make install
+# sudo gdb qemu-system-x86_64
+GNU gdb 6.8-debian
+Copyright (C) 2008 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
+and "show warranty" for details.
+This GDB was configured as "x86_64-linux-gnu"...
+(gdb) r test.img
+Starting program: /usr/local/bin/qemu-system-x86_64 test.img
+[Thread debugging using libthread_db enabled]
+[New Thread 0x7f0730e906f0 (LWP 9790)]
+[New Thread 0x7f072ef12950 (LWP 9793)]
+[New Thread 0x7f072549b950 (LWP 9794)]
+VNC server running on `127.0.0.1:5900'
+
+(qemu) savevm    // works fine
+(qemu) savevm    // crash!!
+
+Program received signal SIGSEGV, Segmentation fault.
+[Switching to Thread 0x7f0730e906f0 (LWP 9790)]
+0x00007f072fa276d2 in strcmp () from /lib/libc.so.6
+(gdb) bt
+#0  0x00007f072fa276d2 in strcmp () from /lib/libc.so.6
+#1  0x00000000004ee0c6 in bdrv_snapshot_find (bs=0x18fd390, sn_info=0x7fffe87dd600, name=0x0) at savevm.c:1632
+#2  0x00000000004ee1b6 in del_existing_snapshots (mon=0x1985800, name=0x0) at savevm.c:1654
+#3  0x00000000004ee41b in do_savevm (mon=0x1985800, qdict=0x1951020) at savevm.c:1722
+#4  0x0000000000416b25 in handle_user_command (mon=0x1985800, cmdline=0x194d0b0 "savevm ")
+    at /home/ght1/Kvm/orig/qemu-kvm-0.12.2/monitor.c:3672
+#5  0x0000000000417d80 in monitor_command_cb (mon=0x1985800, cmdline=0x194d0b0 "savevm ", opaque=0x0)
+    at /home/ght1/Kvm/orig/qemu-kvm-0.12.2/monitor.c:4180
+#6  0x00000000004c3657 in readline_handle_byte (rs=0x194d0b0, ch=13) at readline.c:369
+#7  0x0000000000417cf9 in monitor_read (opaque=0x1985800, buf=0x7fffe87ddca0 "\r�}��\177", size=1)
+    at /home/ght1/Kvm/orig/qemu-kvm-0.12.2/monitor.c:4166
+#8  0x00000000004e6a0d in qemu_chr_read (s=0x18f8110, buf=0x7fffe87ddca0 "\r�}��\177", len=1) at qemu-char.c:154
+#9  0x00000000004c5cd7 in kbd_send_chars (opaque=0x19856c0) at console.c:1130
+#10 0x00000000004c5f22 in kbd_put_keysym (keysym=65293) at console.c:1183
+#11 0x0000000000506799 in do_key_event (vs=0x1bd3420, down=1, keycode=28, sym=65293) at vnc.c:1630
+#12 0x00000000005067fb in key_event (vs=0x1bd3420, down=1, sym=65293) at vnc.c:1647
+#13 0x0000000000507738 in protocol_client_msg (vs=0x1bd3420, data=0x194fc10 "\004\001y", len=8) at vnc.c:1936
+#14 0x0000000000505c2f in vnc_client_read (opaque=0x1bd3420) at vnc.c:1303
+#15 0x000000000040c73b in main_loop_wait (timeout=1000) at /home/ght1/Kvm/orig/qemu-kvm-0.12.2/vl.c:3999
+#16 0x000000000042dcf9 in kvm_main_loop () at /home/ght1/Kvm/orig/qemu-kvm-0.12.2/qemu-kvm.c:2121
+#17 0x000000000040cde4 in main_loop () at /home/ght1/Kvm/orig/qemu-kvm-0.12.2/vl.c:4209
+#18 0x00000000004108dc in main (argc=2, argv=0x7fffe87de598, envp=0x7fffe87de5b0)
+    at /home/ght1/Kvm/orig/qemu-kvm-0.12.2/vl.c:6235
+
+The file "test.img" is a Qemu Image, Format: Qcow , Version: 2 with a clean Debian 5.0 install. I have the same issue with Windows XP.
+
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+