Bug 969084

Summary: crash in qemu from spice validate_virt after adding spice vdagent channel
Product: [Fedora] Fedora Reporter: Zbigniew Jędrzejewski-Szmek <zbyszek>
Component: qemuAssignee: Cole Robinson <crobinso>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: alevy, alexl, amit.shah, berrange, cfergeau, crobinso, dwmw2, hdegoede, itamar, jforbes, marcandre.lureau, pbonzini, rjones, sandmann, scottt.tw, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
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 16:59:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
dumpxml output none

Description Zbigniew Jędrzejewski-Szmek 2013-05-30 15:38:12 UTC
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 20:31:16 UTC
Created attachment 755042 [details]
dumpxml output

virsh --connect qemu:///system dumpxml fedoratestday > fedoratestday.xml

Comment 2 Cole Robinson 2013-06-11 19:31:41 UTC
Looks to be entirely in spice

Comment 3 Hans de Goede 2013-08-01 13:08:12 UTC
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 15:32:52 UTC
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 21:58:37 UTC
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 16:59:29 UTC
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.