Bug 969084 - crash in qemu from spice validate_virt after adding spice vdagent channel
crash in qemu from spice validate_virt after adding spice vdagent channel
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
19
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Cole Robinson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-30 11:38 EDT by Zbigniew Jędrzejewski-Szmek
Modified: 2013-08-09 12:59 EDT (History)
16 users (show)

See Also:
Fixed In Version: qemu-1.4.2-6.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-09 12:59:29 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)
dumpxml output (3.76 KB, text/plain)
2013-05-30 16:31 EDT, Zbigniew Jędrzejewski-Szmek
no flags Details

  None (edit)
Description Zbigniew Jędrzejewski-Szmek 2013-05-30 11:38:12 EDT
Description of problem:
Running testday-20130530-i686.iso for Fedora spice test day in virt-manager.
After running "add hardware" to enable the vdagent channel, I tried to reboot the machine from inside by typing 'reboot'. qemu crashed.

Version-Release number of selected component (if applicable):
host:
libvirt-daemon-driver-qemu-1.0.5.1-1.fc19.x86_64
qemu-kvm-1.4.2-2.fc19.x86_64
qemu-common-1.4.2-2.fc19.x86_64
qemu-system-x86-1.4.2-2.fc19.x86_64
virt-manager-0.10.0-0.5.gitde1695b2.fc19.noarch

How reproducible:
Don't know yet.

Core was generated by `/usr/bin/qemu-system-x86_64 -machine accel=kvm -name fedoratestday -S -machine'.
Program terminated with signal 6, Aborted.
#0  0x00007f7265bdd819 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0  0x00007f7265bdd819 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f7265bdef28 in __GI_abort () at abort.c:90
#2  0x00007f72669932dc in spice_logv (log_domain=0x7f7266a09086 "Spice", log_level=SPICE_LOG_LEVEL_CRITICAL, 
    strloc=0x7f7266a0e009 "red_memslots.c:94", function=0x7f7266a0e18f <__FUNCTION__.18802> "validate_virt", 
    format=0x7f7266a0de98 "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=args@entry=0x7f72567fc728) at log.c:109
#3  0x00007f7266993428 in spice_log (log_domain=log_domain@entry=0x7f7266a09086 "Spice", 
    log_level=log_level@entry=SPICE_LOG_LEVEL_CRITICAL, strloc=strloc@entry=0x7f7266a0e009 "red_memslots.c:94", 
    function=function@entry=0x7f7266a0e18f <__FUNCTION__.18802> "validate_virt", 
    format=format@entry=0x7f7266a0de98 "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") at log.c:123
#4  0x00007f72669534f1 in validate_virt (info=<optimized out>, virt=13548544, slot_id=1, add_size=191, group_id=1)
    at red_memslots.c:90
#5  0x00007f726695360b in get_virt (info=info@entry=0x7f72001d5e58, addr=<optimized out>, add_size=add_size@entry=191, 
    group_id=group_id@entry=1, error=error@entry=0x7f72567fc8bc) at red_memslots.c:142
#6  0x00007f726695516f in red_get_native_drawable (flags=0, addr=<optimized out>, red=0x7f72023f6050, group_id=1, 
    slots=0x7f72001d5e58) at red_parse_qxl.c:939
#7  red_get_drawable (slots=slots@entry=0x7f72001d5e58, group_id=1, red=red@entry=0x7f72023f6050, addr=<optimized out>, flags=0)
    at red_parse_qxl.c:1110
#8  0x00007f726696a502 in red_process_commands (worker=worker@entry=0x7f72000008c0, 
    ring_is_empty=ring_is_empty@entry=0x7f72567fca6c, max_pipe_size=50) at red_worker.c:5207
#9  0x00007f726696d51b in flush_display_commands (worker=worker@entry=0x7f72000008c0) at red_worker.c:9725
#10 0x00007f726696dc78 in flush_all_qxl_commands (worker=0x7f72000008c0) at red_worker.c:9808
#11 dev_destroy_primary_surface (worker=0x7f72000008c0, surface_id=0) at red_worker.c:11481
#12 0x00007f7266950de8 in dispatcher_handle_single_read (dispatcher=0x7f726e570a38) at dispatcher.c:139
#13 dispatcher_handle_recv_read (dispatcher=0x7f726e570a38) at dispatcher.c:162
#14 0x00007f726697342d in red_worker_main (arg=<optimized out>) at red_worker.c:12289
#15 0x00007f726abbdc53 in start_thread (arg=0x7f72567fd700) at pthread_create.c:308
#16 0x00007f7265c9cecd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
Comment 1 Zbigniew Jędrzejewski-Szmek 2013-05-30 16:31:16 EDT
Created attachment 755042 [details]
dumpxml output

virsh --connect qemu:///system dumpxml fedoratestday > fedoratestday.xml
Comment 2 Cole Robinson 2013-06-11 15:31:41 EDT
Looks to be entirely in spice
Comment 3 Hans de Goede 2013-08-01 09:08:12 EDT
Thanks for the bug-report. Cole this is caused by some uninitialized memory in the qxl code in qemu, which is fixed by this commit:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=329f97fc4ff4b533fcd2d8f4eab6c9c2568aed27

Cole, can you please add this commit  to the next Fedora-19 qemu build?
Comment 4 Fedora Update System 2013-08-01 11:32:52 EDT
qemu-1.4.2-6.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/qemu-1.4.2-6.fc19
Comment 5 Fedora Update System 2013-08-02 17:58:37 EDT
Package qemu-1.4.2-6.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing qemu-1.4.2-6.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-14103/qemu-1.4.2-6.fc19
then log in and leave karma (feedback).
Comment 6 Fedora Update System 2013-08-09 12:59:29 EDT
qemu-1.4.2-6.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

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