Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
(In reply to Gerd Hoffmann from comment #5)
> Why "Severity high"?
Hi Gerd,
this makes qemu crash, so I think it's a serious problem,
if you think the priority should change, pls do it :-)
Hi,
> this makes qemu crash, so I think it's a serious problem,
> if you think the priority should change, pls do it :-)
It isn't in that case. It isn't a crash, it is sanity check failing in spice-server and spice-server handles it by stopping the qemu process using abort(). So it isn't critical from a security point of view. Also it happens when doing device robustness testing, not in normal guest operation, so customers should not be affected by this issue.
Doing abort() on failed sanity checks isn't exactly nice to the guest, we are trying to get rid of those cases. It isn't always easy though, it also is a low priority thing, and we care about it only for upstream and maybe latest rhel.
Therefore this is a WONTFIX for rhel6.
Description of problem: qemu core dump on iofuzz test Version-Release number of selected component (if applicable): qemu-kvm-rhev-0.12.1.2-2.440.el6.x86_64 spice-server-0.12.4-11.el6.x86_64 How reproducible: 1/1 Steps to Reproduce: 1. launch iofuzz in autotest python ConfigTest.py --driveformat=virtio_scsi --display=spice --guestname=RHEL.6.6 --testcase=iofuzz /usr/bin/qemu-kvm \ -S \ -name 'virt-tests-vm1' \ -M rhel6.6.0 \ -nodefaults \ -vga qxl \ -global qxl-vga.vram_size=33554432 \ -device AC97,bus=pci.0,addr=03 \ -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20140822-014741-JVg2OLJF,server,nowait \ -mon chardev=qmp_id_qmpmonitor1,mode=control \ -chardev socket,id=serial_id_serial0,path=/tmp/serial-serial0-20140822-014741-JVg2OLJF,server,nowait \ -device isa-serial,chardev=serial_id_serial0 \ -chardev socket,id=seabioslog_id_20140822-014741-JVg2OLJF,path=/tmp/seabios-20140822-014741-JVg2OLJF,server,nowait \ -device isa-debugcon,chardev=seabioslog_id_20140822-014741-JVg2OLJF,iobase=0x402 \ -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=04 \ -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=05 \ -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,file=/usr/local/staf/test/RHEV/kvm/autotest-devel/client/tests/virt/shared/data/images/RHEL-Server-6.6-64-virtio.qcow2 \ -device scsi-hd,id=image1,drive=drive_image1 \ -device virtio-net-pci,mac=9a:0f:10:11:12:13,id=idW7A4dg,vectors=4,netdev=idhyYbTM,bus=pci.0,addr=06 \ -netdev tap,id=idhyYbTM,vhost=on,vhostfd=28,fd=27 \ -m 4096 \ -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \ -cpu 'SandyBridge' \ -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \ -spice port=3000,password=123456,addr=0,image-compression=auto_glz,zlib-glz-wan-compression=auto,streaming-video=all,agent-mouse=on,playback-compression=on,ipv4 \ -rtc base=utc,clock=host,driftfix=slew \ -boot order=cdn,once=c,menu=off \ -no-kvm-pit-reinjection \ -enable-kvm 2. 3. Actual results: qemu crashed, analyzed core dump (gdb) bt #0 0x00007fd275686915 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007fd2756880f5 in abort () at abort.c:92 #2 0x00007fd275ee9095 in spice_logv (log_domain=0x7fd275f60226 "Spice", log_level=SPICE_LOG_LEVEL_CRITICAL, strloc=0x7fd275f64fda "red_memslots.c:94", function=0x7fd275f650bf "validate_virt", format=0x7fd275f64de8 "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=0x7fd1589fa860) at log.c:109 #3 0x00007fd275ee91ca 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 0x00007fd275ea69c3 in validate_virt (info=<value optimized out>, virt=0, slot_id=1, add_size=3145728, group_id=1) at red_memslots.c:90 #5 0x00007fd275ea6b13 in get_virt (info=<value optimized out>, addr=<value optimized out>, add_size=<value optimized out>, group_id=1, error=0x7fd1589faa4c) at red_memslots.c:142 #6 0x00007fd275eb4f3d in dev_create_primary_surface (worker=0x7fd1500008c0, surface_id=<value optimized out>, surface=...) at red_worker.c:11335 #7 0x00007fd275eb5520 in handle_dev_create_primary_surface (opaque=<value optimized out>, payload=<value optimized out>) at red_worker.c:11371 #8 0x00007fd275ea40a7 in dispatcher_handle_single_read (dispatcher=0x7fd27ab5e8a8) at dispatcher.c:139 #9 dispatcher_handle_recv_read (dispatcher=0x7fd27ab5e8a8) at dispatcher.c:162 #10 0x00007fd275ebfa86 in red_worker_main (arg=<value optimized out>) at red_worker.c:12200 #11 0x00007fd2785329d1 in start_thread (arg=0x7fd1589fb700) at pthread_create.c:301 #12 0x00007fd27573cccd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 Expected results: qemu run smoothly Additional info: