Bug 995931 - Qemu core dump (red_get_image: unknown type 184) when reboot a RHEL.6.4-64 guest 25 times
Qemu core dump (red_get_image: unknown type 184) when reboot a RHEL.6.4-64 gu...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.5
Unspecified Unspecified
medium Severity high
: rc
: ---
Assigned To: Gerd Hoffmann
Virtualization Bugs
:
: 952447 1077076 (view as bug list)
Depends On:
Blocks: 1054077 1077076
  Show dependency treegraph
 
Reported: 2013-08-11 23:42 EDT by CongLi
Modified: 2015-10-29 01:15 EDT (History)
21 users (show)

See Also:
Fixed In Version: qemu-kvm-0.12.1.2-2.438.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-10-14 02:49:56 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description CongLi 2013-08-11 23:42:47 EDT
Description of problem:
Qemu core dump when reboot a RHEL.6.4-64 guest 25 times

Version-Release number of selected component (if applicable):
kernel-2.6.32-410.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.386.el6
spice-server-0.12.4-1.el6.x86_64

How reproducible:
1 / 1

Steps to Reproduce:
1. Boot a RHEL.6.4-64 guest with CML:
/usr/local/staf/test/RHEV/kvm-new/autotest/client/tests/kvm/qemu \
-name 'vm1' \
-nodefaults \
-chardev socket,id=qmp_monitor_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20130810-042116-3xjo,server,nowait \
-mon chardev=qmp_monitor_id_qmpmonitor1,mode=control \
-chardev socket,id=serial_id_20130810-042116-3xjo,path=/tmp/serial-20130810-042116-3xjo,server,nowait \
-device isa-serial,chardev=serial_id_20130810-042116-3xjo \
-device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=0x4 \
-drive file='/usr/local/staf/test/RHEV/kvm-new/autotest/client/tests/kvm/images/RHEL-Server-6.4-64-virtio.qcow2',if=none,id=drive-virtio-disk1,media=disk,cache=none,boot=off,snapshot=off,format=qcow2,aio=native \
-device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 \
-device virtio-net-pci,netdev=idOdGse2,mac=9a:01:62:6c:55:f4,id=ndev00idOdGse2,bus=pci.0,addr=0x3 \
-netdev tap,id=idOdGse2,vhost=on,fd=26 \
-m 2048 \
-smp 1,cores=0,threads=1,sockets=2 \
-cpu 'Opteron_G2' \
-device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
-spice port=3000,password=123456,addr=0,tls-port=3200,x509-dir=/tmp/spice_x509d,tls-channel=main,tls-channel=inputs,image-compression=auto_glz,jpeg-wan-compression=auto,zlib-glz-wan-compression=auto,streaming-video=all,agent-mouse=on,playback-compression=on,ipv4 \
-vga qxl \
-global qxl-vga.vram_size=33554432 \
-rtc base=utc,clock=host,driftfix=slew \
-M rhel6.5.0 \
-boot order=cdn,once=c,menu=off \
-no-kvm-pit-reinjection \
-enable-kvm 

2. Reboot guest

3. Wait until the guest is up again & Log into the guest to verify it's up again

4. Repeat step 2 & step 3 for 25 times.

Actual results:
Qemu core dump.

Expected results:
Qemu works well.

Additional info:
1. cpuinfo:
processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 107
model name	: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+
stepping	: 2
cpu MHz		: 1000.000
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch lbrv
bogomips	: 2004.10
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps

2. gdb:
Core was generated by `/usr/local/staf/test/RHEV/kvm-new/autotest/client/tests/kvm/qemu -name vm1 -nod'.
Program terminated with signal 6, Aborted.
#0  0x00007ffdd40e48a5 in raise () from /lib64/libc.so.6
#0  0x00007ffdd40e48a5 in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007ffdd40e6085 in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007ffdd4945385 in spice_logv (log_domain=0x7ffdd49bc526 "Spice", log_level=SPICE_LOG_LEVEL_ERROR, strloc=0x7ffdd49c1122 "red_parse_qxl.c:489", function=0x7ffdd49c1673 "red_get_image", format=0x7ffdd49c1112 "unknown type %d", args=0x7ffdc4dfc750) at log.c:109
        level = 0x7ffdd49cbfc2 "ERROR"
#3  0x00007ffdd49454ba in spice_log (log_domain=<value optimized out>, log_level=<value optimized out>, strloc=<value optimized out>, function=<value optimized out>, format=<value optimized out>) at log.c:123
        args = {{gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x7ffdc4dfc830, reg_save_area = 0x7ffdc4dfc770}}
#4  0x00007ffdd49039f3 in red_get_image (slots=0x7ffd341d5e58, group_id=1, addr=72057594054719520, flags=0, is_mask=0) at red_parse_qxl.c:489
        chunks = {data_size = 15, prev_chunk = 0x3, next_chunk = 0x7ffdc4dfc92c, data = 0x7ffd3cc03758 "X\250\250\300[\177"}
        qxl = <value optimized out>
        red = 0x7ffd3421ff90
        rp = 0x0
        bitmap_size = <value optimized out>
        size = <value optimized out>
        qxl_flags = <value optimized out>
        error = 0
        __FUNCTION__ = "red_get_image"
#5  0x00007ffdd4903fdb in red_get_copy_ptr (slots=0x7ffd341d5e58, group_id=1, red=0x7ffd3421ff30, qxl=0x7ffd3cc037d3, flags=0) at red_parse_qxl.c:590
No locals.
#6  0x00007ffdd49050d9 in red_get_native_drawable (slots=0x7ffd341d5e58, group_id=1, red=0x7ffd3421fea0, addr=<value optimized out>, flags=0) at red_parse_qxl.c:967
        qxl = <value optimized out>
        i = <value optimized out>
        error = 0
#7  red_get_drawable (slots=0x7ffd341d5e58, group_id=1, red=0x7ffd3421fea0, addr=<value optimized out>, flags=0) at red_parse_qxl.c:1105
        ret = <value optimized out>
#8  0x00007ffdd49190cb in red_process_commands (worker=0x7ffd340008c0, ring_is_empty=0x7ffdc4dfcbdc, max_pipe_size=50) at red_worker.c:5190
        red_drawable = 0x7ffd3421fea0
        ext_cmd = {cmd = {data = 72057594054719320, type = 1, padding = 0}, group_id = 1, flags = 0}
        n = 0
        start = 18446737191986552835
#9  0x00007ffdd491c09e in red_worker_main (arg=<value optimized out>) at red_worker.c:12292
        ring_is_empty = 0
        i = <value optimized out>
        num_events = 1
        timers_queue_timeout = <value optimized out>
        worker = 0x7ffd340008c0
        __FUNCTION__ = "red_worker_main"
#10 0x00007ffdd60e4851 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#11 0x00007ffdd419a90d in clone () from /lib64/libc.so.6
No symbol table info available.

3. gdb info:
(/usr/local/staf/test/RHEV/kvm-new/autotest/client/tests/kvm/qemu:1708): Spice-ERROR **: red_parse_qxl.c:489:red_get_image: unknown type 184
Thread 4 (Thread 0x7ffdcce5f700 (LWP 1712)):
#0  0x00007ffdd60eb054 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007ffdd60e6388 in _L_lock_854 () from /lib64/libpthread.so.0
#2  0x00007ffdd60e6257 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00007ffdd67b207a in kvm_main_loop_wait (env=0x7ffdd91fa8d0, timeout=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/qemu-kvm.c:1874
#4  0x00007ffdd67b26cd in kvm_main_loop_cpu (_env=0x7ffdd91fa8d0) at /usr/src/debug/qemu-kvm-0.12.1.2/qemu-kvm.c:2007
#5  ap_main_loop (_env=0x7ffdd91fa8d0) at /usr/src/debug/qemu-kvm-0.12.1.2/qemu-kvm.c:2060
#6  0x00007ffdd60e4851 in start_thread () from /lib64/libpthread.so.0
#7  0x00007ffdd419a90d in clone () from /lib64/libc.so.6
Thread 3 (Thread 0x7ffdc4dfd700 (LWP 1713)):
#0  0x00007ffdd60eb54d in read () from /lib64/libpthread.so.0
#1  0x00007ffdd493d250 in read () at /usr/include/bits/unistd.h:45
#2  spice_backtrace_gstack () at backtrace.c:100
#3  0x00007ffdd4945380 in spice_logv (log_domain=0x7ffdd49bc526 "Spice", log_level=SPICE_LOG_LEVEL_ERROR, strloc=0x7ffdd49c1122 "red_parse_qxl.c:489", function=0x7ffdd49c1673 "red_get_image", format=0x7ffdd49c1112 "unknown type %d", args=0x7ffdc4dfc750) at log.c:108
#4  0x00007ffdd49454ba in spice_log (log_domain=<value optimized out>, log_level=<value optimized out>, strloc=<value optimized out>, function=<value optimized out>, format=<value optimized out>) at log.c:123
#5  0x00007ffdd49039f3 in red_get_image (slots=0x7ffd341d5e58, group_id=1, addr=72057594054719520, flags=0, is_mask=0) at red_parse_qxl.c:489
#6  0x00007ffdd4903fdb in red_get_copy_ptr (slots=0x7ffd341d5e58, group_id=1, red=0x7ffd3421ff30, qxl=0x7ffd3cc037d3, flags=0) at red_parse_qxl.c:590
#7  0x00007ffdd49050d9 in red_get_native_drawable (slots=0x7ffd341d5e58, group_id=1, red=0x7ffd3421fea0, addr=<value optimized out>, flags=0) at red_parse_qxl.c:967
#8  red_get_drawable (slots=0x7ffd341d5e58, group_id=1, red=0x7ffd3421fea0, addr=<value optimized out>, flags=0) at red_parse_qxl.c:1105
#9  0x00007ffdd49190cb in red_process_commands (worker=0x7ffd340008c0, ring_is_empty=0x7ffdc4dfcbdc, max_pipe_size=50) at red_worker.c:5190
#10 0x00007ffdd491c09e in red_worker_main (arg=<value optimized out>) at red_worker.c:12292
#11 0x00007ffdd60e4851 in start_thread () from /lib64/libpthread.so.0
#12 0x00007ffdd419a90d in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7ffdce9fd700 (LWP 2882)):
#0  0x00007ffdd60e87bb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007ffdd67d0087 in cond_timedwait (unused=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/posix-aio-compat.c:102
#2  aio_thread (unused=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/posix-aio-compat.c:329
#3  0x00007ffdd60e4851 in start_thread () from /lib64/libpthread.so.0
#4  0x00007ffdd419a90d in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7ffdd66ff980 (LWP 1708)):
#0  0x00007ffdd60eb54d in read () from /lib64/libpthread.so.0
#1  0x00007ffdd4900003 in read (fd=45, buf=0x7fff10a3ddcc "\375\177", size=4, block=<value optimized out>) at /usr/include/bits/unistd.h:45
#2  read_safe (fd=45, buf=0x7fff10a3ddcc "\375\177", size=4, block=<value optimized out>) at dispatcher.c:76
#3  0x00007ffdd4900236 in dispatcher_send_message (dispatcher=0x7ffdd92239f8, message_type=16, payload=0x7fff10a3de00) at dispatcher.c:188
#4  0x00007ffdd490082c in red_dispatcher_add_memslot (qxl_worker=<value optimized out>, mem_slot=<value optimized out>) at red_dispatcher.c:386
#5  qxl_worker_add_memslot (qxl_worker=<value optimized out>, mem_slot=<value optimized out>) at red_dispatcher.c:393
#6  0x00007ffdd6822555 in qemu_spice_create_host_memslot (ssd=0x7ffdd9c1cab0) at /usr/src/debug/qemu-kvm-0.12.1.2/ui/spice-display.c:333
#7  0x00007ffdd692e989 in qxl_hard_reset (d=0x7ffdd9c1c840, loadvm=0) at /usr/src/debug/qemu-kvm-0.12.1.2/hw/qxl.c:1108
#8  0x00007ffdd678a762 in qemu_system_reset (report=true) at /usr/src/debug/qemu-kvm-0.12.1.2/vl.c:3332
#9  0x00007ffdd67af720 in qemu_kvm_system_reset (report=true) at /usr/src/debug/qemu-kvm-0.12.1.2/qemu-kvm.c:1978
#10 0x00007ffdd67af923 in kvm_main_loop () at /usr/src/debug/qemu-kvm-0.12.1.2/qemu-kvm.c:2258
#11 0x00007ffdd6790728 in main_loop (argc=44, argv=<value optimized out>, envp=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/vl.c:4260
#12 main (argc=44, argv=<value optimized out>, envp=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/vl.c:6631
Comment 3 Laszlo Ersek 2013-08-12 19:07:11 EDT
How exactly do you reboot the guest in comment #0 step 2? Thanks.
Comment 4 Laszlo Ersek 2013-08-12 19:19:47 EDT
My guess is that spice might need a reset notifier. The spice protocol byte stream could be abruptly restarted in the middle of a command.
Comment 5 CongLi 2013-08-12 22:23:06 EDT
(In reply to Laszlo Ersek from comment #3)
> How exactly do you reboot the guest in comment #0 step 2? Thanks.

Login guest via ssh, then do 'shutdown -r now' in guest.
Comment 6 Laszlo Ersek 2013-08-13 06:55:37 EDT
Okay I've looked into some recent spice-server patches and they convinced me that the spice guys will be able to narrow this down (to get the component right, even) much faster than I could. Moving to spice-server; feel free to bump back if I'm wrong. Spice-server version is captured in comment #0. Thanks.
Comment 7 Laszlo Ersek 2013-08-13 08:26:32 EDT
Thread 1: IO thread
Thread 2: AIO thread
Thread 3: QXL worker thread
Thread 4: VCPU thread

Thread 1, the IO thread, is running qxl_hard_reset(), the QXL reset notification handler, as part of the VM reset. This operation seems to send a message of type RED_WORKER_MESSAGE_ADD_MEMSLOT to thread 3, the QXL worker thread.

qxl_hard_reset()
  qemu_spice_create_host_memslot()

    memslot.slot_group_id     = MEMSLOT_GROUP_HOST
    memslot.slot_id           = 0
    memslot.generation        = 0
    memslot.virt_start        = 0
    memslot.virt_end          = ~0UL
    memslot.addr_delta        = 0
    memslot.virt_qxl_ram_size = 0

    qemu_spice_add_memslot(memslot, ..., QXL_SYNC)
      qxl_worker_add_memslot() -- via funcptr
        red_dispatcher_add_memslot()
          dispatcher_send_message(..., RED_WORKER_MESSAGE_ADD_MEMSLOT)
            -- sends message
            -- is waiting for ACK

Thread 3, the QXL worker thread, handles RED_WORKER_MESSAGE_ADD_MEMSLOT:

handle_dev_add_memslot()
  red_memslot_info_add_slot()
    -- stores addr_delta (0) / virt_start (0) /
              virt_end (~0UL) / generation (0)
       in
         info->mem_slots[slot_group_id][slot_id], that is,
         info->mem_slots[MEMSLOT_GROUP_HOST][0],

Thread 3, the QXL worker thread, goes on to process a QXL_CMD_DRAW command:

red_worker_main()
  red_process_commands()
    red_get_drawable()
      red_get_native_drawable() -- QXL_COMMAND_FLAG_COMPAT is clear
        red_get_copy_ptr() -- red->type == QXL_DRAW_COPY
          red_get_image()

            qxl                  = get_virt(...)
            red->descriptor.type = qxl->descriptor.type
            -- cannot handle this unknown type

Now, get_virt() tries to translate a (guest?)physical address to a host virtual address, and then work with the image found there.

Unfortunately, the pointer returned by qxl is garbage, which points into garbage. This is because get_virt() implements the gpa->hva resolution by traversing the memmap that the RED_WORKER_MESSAGE_ADD_MEMSLOT command just destroyed.

So, my interpretation: when the QXL reset handler is run in the IO thread, it queues a synchronous RED_WORKER_MESSAGE_ADD_MEMSLOT message for the QXL worker thread. This message clears the memmap that the QXL worker thread is maintaining. Apparently, the command queue of the QXL worker is not flushed at this point (although it should be), because the QXL worker tries to process another message (that has been queued earlier), of type QXL_CMD_DRAW. This message is unprocessable with the cleared memmap.

This could also be a synchronization problem between the IO thread and the QXL worker thread. Maybe the QXL work queue *is* flushed before sending the RED_WORKER_MESSAGE_ADD_MEMSLOT command, but (perhaps) the QXL_CMD_DRAW command is unexpectedly enqueued afterwards.

The "synchronization problem" theory is supported by the fact that QE had to run the test 25 times to trigger the problem once. Maybe heavy graphics activity in the guest, combined with the more abrupt "system_reset" HMP command (which doesn't stop guest processes nicely, like "shutdown -r now"), could trigger it with a higher rate.
Comment 8 RHEL Product and Program Management 2013-10-13 22:46:23 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 9 Marc-Andre Lureau 2014-06-18 18:29:31 EDT
*** Bug 952447 has been marked as a duplicate of this bug. ***
Comment 10 Marc-Andre Lureau 2014-06-18 18:43:15 EDT
raising a bit severity to highlight that bug, although it's not critical, since a crash when the guest reboot is somehow "safe"
Comment 11 Marc-Andre Lureau 2014-06-19 14:54:19 EDT
Ok, it looks like rhel is missing this fix:

commit 75c70e37bc4a6bdc394b4d1b163fe730abb82c72
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Mon Dec 9 16:03:49 2013 +0100

    spice: stop server for qxl hard reset

Gerd, why did you propose that fix for RHEL too? otherwise, I think it's a good time :)
Comment 12 Marc-Andre Lureau 2014-06-19 14:57:16 EDT
moving to POST to reflect that
Comment 16 Ademar Reis 2014-06-24 09:37:15 EDT
(In reply to Marc-Andre Lureau from comment #11)
> Ok, it looks like rhel is missing this fix:
> 
> commit 75c70e37bc4a6bdc394b4d1b163fe730abb82c72
> Author: Gerd Hoffmann <kraxel@redhat.com>
> Date:   Mon Dec 9 16:03:49 2013 +0100
> 
>     spice: stop server for qxl hard reset
> 
> Gerd, why did you propose that fix for RHEL too? otherwise, I think it's a
> good time :)

(In reply to Marc-Andre Lureau from comment #12)
> moving to POST to reflect that

The patch should be backported - I don't see the patch in rhvirt-patches. We only move bugs to POST after it's posted downstream, not when it's upstream.

Moving it back to assigned, owned by Gerd. Please correct me if I'm wrong.
Comment 17 Marc-Andre Lureau 2014-06-26 19:55:21 EDT
please try with this new scratchbuild
https://brewweb.devel.redhat.com/taskinfo?taskID=7632466

thanks

There was a second patch needed:
commit b50f3e42b9438e033074222671c0502ecfeba82c
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Mon Dec 9 16:00:15 2013 +0100

    spice: move spice_server_vm_{start,stop} calls into qemu_spice_display_*()

Gerd, are you taking this over? thanks
Comment 18 Xiaoqing Wei 2014-06-30 08:44:46 EDT
(In reply to Marc-Andre Lureau from comment #17)
> please try with this new scratchbuild
> https://brewweb.devel.redhat.com/taskinfo?taskID=7632466
> 
> thanks

Tested 10 rounds, each round needs 50 times' reboot, all pass.

package version:
kernel-2.6.32-431.22.1.el6.x86_64
qemu-kvm-0.12.1.2-2.415.el6_5.11.x86_64

As the above info, I think this bug has been fixed in the above build.

If there is anything wrong, feel free to correct me.

Thanks,
Cong
Comment 19 Marc-Andre Lureau 2014-06-30 09:58:50 EDT
*** Bug 1077076 has been marked as a duplicate of this bug. ***
Comment 20 Marc-Andre Lureau 2014-06-30 10:02:59 EDT
Thanks in advance Gerd! :)
Comment 22 Gerd Hoffmann 2014-07-02 06:42:28 EDT
http://brewweb.devel.redhat.com/brew/taskinfo?taskID=7657369
patches posted.
Comment 25 Marc-Andre Lureau 2014-07-03 18:33:17 EDT
do we need a duplicate for rhel7?
Comment 26 Gerd Hoffmann 2014-07-04 05:25:41 EDT
(In reply to Marc-Andre Lureau from comment #25)
> do we need a duplicate for rhel7?

No, 1.5.0 has the patches.
Comment 27 Jeff Nelson 2014-08-13 11:58:37 EDT
Fix included in qemu-kvm-0.12.1.2-2.438.el6
Comment 32 langfang 2014-08-26 02:36:27 EDT
Test this bug as follow version,still can not reproduce

Host:
# uname -r
2.6.32-410.el6.x86_64
# rpm -q qemu-kvm-rhev
qemu-kvm-rhev-0.12.1.2-2.386.el6_5.test.x86_64

Guest:RHEL6.4

Steps:
1.Boot RHEL6.4guest
2.Login and Reboot guest

Use autotest script for the test
 #python ConfigTest.py --guestname=RHEL.6.4 --testcase=reboot  --nrepeat=10
 
  login (ssh)-->reboot(shutdown -r now)

3. Repeat step 2 for 25 *10=250 times.

Actual results:
guest work well

Attdional info:

According comment7, manually test about 10 times ,each time  add GUI stress(use SPECviewperf) in guest, still can not reproduce.


Test on latest version:

Host:
kernel-2.6.32-431.31.1.el6.x86_64
qemu-kvm-0.12.1.2-2.438.el6.x86_64

guest:

RHEL6.4-GA

Results:

Test about 25*50 times ,guest work well
Comment 33 Chao Yang 2014-08-27 00:55:25 EDT
Reproduced on qemu-kvm-0.12.1.2-2.437.el6.x86_64 and spice-server-0.12.4-2.el6.x86_64.

Steps:
1. start a rhel7 guest by:
/usr/libexec/qemu-kvm -name test -M rhel6.0.0 -enable-kvm -cpu Penryn -m 2048 -smp 2,sockets=2,cores=1,threads=1 -nodefaults -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=00:1a:4a:42:76:36,bus=pci.0 -k en-us -vga qxl -spice port=7000,disable-ticketing,streaming-video=all,agent-mouse=on,playback-compression=on  -usb -monitor stdio -boot menu=on -drive file=/home/RHEL-Server-7.0-64.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,werror=stop,rerror=stop,aio=native -device ide-drive,bus=ide.0,unit=0,drive=drive-virtio-disk0,id=virtio-disk0

2. login to guest

3. system_reset through HMP

Actual Result:
(qemu) system_reset 
(qemu) id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0, delta 0
(/usr/bin/gdb:28539): Spice-CRITICAL **: red_memslots.c:94:validate_virt: virtual address out of range
    virt=0x1000398+0xbf slot_id=1 group_id=1
    slot=0x0-0x0 delta=0x0
Detaching after fork from child process 28690.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe65fd700 (LWP 28555)]
0x00007ffff483e915 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff483e915 in raise () from /lib64/libc.so.6
#1  0x00007ffff48400f5 in abort () from /lib64/libc.so.6
#2  0x00007ffff50a0875 in spice_logv (log_domain=0x7ffff5117a06 "Spice", log_level=SPICE_LOG_LEVEL_CRITICAL, strloc=0x7ffff511c43a "red_memslots.c:94", 
    function=0x7ffff511c51f "validate_virt", format=0x7ffff511c248 "virtual address out of range\n    virt=0x%lx+0x%x slot_id=%d group_id=%d\n    slot=0x%lx-0x%lx delta=0x%lx", 
    args=0x7fffe65fc660) at log.c:109
#3  0x00007ffff50a09aa in spice_log (log_domain=<value optimized out>, log_level=<value optimized out>, strloc=<value optimized out>, function=<value optimized out>, 
    format=<value optimized out>) at log.c:123
#4  0x00007ffff505df23 in validate_virt (info=<value optimized out>, virt=16778136, slot_id=1, add_size=191, group_id=1) at red_memslots.c:90
#5  0x00007ffff505e073 in get_virt (info=<value optimized out>, addr=<value optimized out>, add_size=<value optimized out>, group_id=1, error=0x7fffe65fc80c) at red_memslots.c:142
#6  0x00007ffff5060060 in red_get_native_drawable (slots=0x7fff501d5e58, group_id=1, red=0x7fff5045cf00, addr=<value optimized out>, flags=0) at red_parse_qxl.c:934
#7  red_get_drawable (slots=0x7fff501d5e58, group_id=1, red=0x7fff5045cf00, addr=<value optimized out>, flags=0) at red_parse_qxl.c:1105
#8  0x00007ffff507447b in red_process_commands (worker=0x7fff500008c0, ring_is_empty=0x7fffe65fca3c, max_pipe_size=50) at red_worker.c:5190
#9  0x00007ffff507755b in flush_display_commands (worker=0x7fff500008c0) at red_worker.c:9712
#10 flush_all_qxl_commands (worker=0x7fff500008c0) at red_worker.c:9795
#11 0x00007ffff5078380 in dev_destroy_surfaces (opaque=<value optimized out>, payload=<value optimized out>) at red_worker.c:11270
#12 handle_dev_destroy_surfaces (opaque=<value optimized out>, payload=<value optimized out>) at red_worker.c:11299
#13 0x00007ffff505b607 in dispatcher_handle_single_read (dispatcher=0x7ffff88b0b68) at dispatcher.c:139
#14 dispatcher_handle_recv_read (dispatcher=0x7ffff88b0b68) at dispatcher.c:162
#15 0x00007ffff5077226 in red_worker_main (arg=<value optimized out>) at red_worker.c:12276
#16 0x00007ffff76e99d1 in start_thread () from /lib64/libpthread.so.0
#17 0x00007ffff48f4ccd in clone () from /lib64/libc.so.6




-- Verified pass with qemu-kvm-0.12.1.2-2.441.el6.x86_64. No qemu-kvm coredump any more after system_reset in HMP. Besides, I tested latest spice-server(spice-server-0.12.4-11.el6.x86_64) with -M rhel6.0.0 as well as -M rhel6.6.0. This issue no longer reproduces.

As per above, this issue has fixed.
Comment 35 errata-xmlrpc 2014-10-14 02:49:56 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1490.html

Note You need to log in before you can comment on or make changes to this bug.