Yanan Fu,

Please provide full qemu command line and the name of host where it reproduces.

(In reply to Igor Mammedov from comment #2)
> Yanan Fu,
> 
> Please provide full qemu command line and the name of host where it
> reproduces.

Hi Igor:
amd host name: hp-dl385pg8-03.rhts.eng.pek2.redhat.com, cpu model "Opteron_G5",listed in Description.
This host already be taken back by beaker, and it is using by other people now.
If this bz is related with HW, we can wait and loan it later.

qemu command line that get from the debug.log in attachment:
MALLOC_PERTURB_=1  /usr/libexec/qemu-kvm \
    -S  \
    -name 'avocado-vt-vm1'  \
    -sandbox off  \
    -machine pc  \
    -nodefaults  \
    -vga qxl \
    -device pci-bridge,id=pci_bridge,bus=pci.0,addr=0x3,chassis_nr=1 \
    -device intel-hda,bus=pci.0,addr=0x4 \
    -device hda-duplex  \
    -chardev socket,id=qmp_id_qmpmonitor1,path=/var/tmp/avocado_Tr9fY9/monitor-qmpmonitor1-20171207-065334-9qZE8GWj,server,nowait \
    -mon chardev=qmp_id_qmpmonitor1,mode=control  \
    -chardev socket,id=qmp_id_catch_monitor,path=/var/tmp/avocado_Tr9fY9/monitor-catch_monitor-20171207-065334-9qZE8GWj,server,nowait \
    -mon chardev=qmp_id_catch_monitor,mode=control \
    -device pvpanic,ioport=0x505,id=idsT5AjV  \
    -chardev socket,id=serial_id_serial0,path=/var/tmp/avocado_Tr9fY9/serial-serial0-20171207-065334-9qZE8GWj,server,nowait \
    -device isa-serial,chardev=serial_id_serial0 \
    -device virtio-serial-pci,id=virtio_serial_pci0,bus=pci.0,addr=0x5 \
    -chardev socket,path=/var/tmp/avocado_Tr9fY9/virtio_port-vs-20171207-065334-9qZE8GWj,nowait,id=idWrJ06X,server \
    -device virtserialport,id=idUScFpH,name=vs,bus=virtio_serial_pci0.0,chardev=idWrJ06X \
    -object rng-random,filename=/dev/random,id=passthrough-XAVGpw58 \
    -device virtio-rng-pci,id=virtio-rng-pci-gflMRhSb,rng=passthrough-XAVGpw58,bus=pci.0,addr=0x6  \
    -chardev socket,id=seabioslog_id_20171207-065334-9qZE8GWj,path=/var/tmp/avocado_Tr9fY9/seabios-20171207-065334-9qZE8GWj,server,nowait \
    -device isa-debugcon,chardev=seabioslog_id_20171207-065334-9qZE8GWj,iobase=0x402 \
    -device ich9-usb-ehci1,id=usb1,addr=0x1d.7,multifunction=on,bus=pci.0 \
    -device ich9-usb-uhci1,id=usb1.0,multifunction=on,masterbus=usb1.0,addr=0x1d.0,firstport=0,bus=pci.0 \
    -device ich9-usb-uhci2,id=usb1.1,multifunction=on,masterbus=usb1.0,addr=0x1d.2,firstport=2,bus=pci.0 \
    -device ich9-usb-uhci3,id=usb1.2,multifunction=on,masterbus=usb1.0,addr=0x1d.4,firstport=4,bus=pci.0 \
    -device nec-usb-xhci,id=usb2,bus=pci.0,addr=0x7 \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x8 \
    -drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/rhel75-64-virtio-scsi.qcow2 \
    -device scsi-hd,id=image1,drive=drive_image1 \
    -device virtio-net-pci,mac=9a:53:54:55:56:57,id=idHUSP5o,vectors=4,netdev=idmXt8FG,bus=pci.0,addr=0x9  \
    -netdev tap,id=idmXt8FG,vhost=on,vhostfd=19,fd=17 \
    -m 8192  \
    -smp 8,maxcpus=8,cores=4,threads=1,sockets=2  \
    -cpu 'Opteron_G5',+kvm_pv_unhalt \
    -device usb-tablet,id=usb-tablet1,bus=usb2.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,zlib-glz-wan-compression=auto,streaming-video=all,agent-mouse=on,playback-compression=on,ipv4  \
    -rtc base=utc,clock=host,driftfix=slew  \
    -boot menu=off,strict=off,order=cdn,once=c  \
    -mem-path /mnt/kvm_hugepage \
    -no-hpet \
    -enable-kvm  \
    -watchdog i6300esb \
    -watchdog-action reset \
    -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0xa

(In reply to Yanan Fu from comment #7)
Thanks for landing it out. Host in no longer needed.

Tested it quite a bit but couldn't reproduce issue on this host either,
so checked attached logs once more and noticed following lines:

07:00:33 INFO | [qemu output] (process:25880): Spice-[1;33mWARNING[0m **: display-channel.c:2431:display_channel_validate_surface: canvas address is 0x562304c45b08 for 0 (and is NULL)
07:00:33 INFO | [qemu output] 
07:00:33 INFO | [qemu output] 
07:00:33 INFO | [qemu output] (process:25880): Spice-[1;33mWARNING[0m **: display-channel.c:2432:display_channel_validate_surface: failed on 0
07:00:33 INFO | [qemu output] 
07:00:33 INFO | [qemu output] (process:25880): Spice-[1;35mCRITICAL[0m **: display-channel.c:2035:display_channel_update: condition `display_channel_validate_surface(display, surface_id)' failed

After looking for similar errors, it seems that others also experience qxl related crashes qand looks like a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1441715

or similar https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884613 and maybe related https://bugzilla.redhat.com/show_bug.cgi?id=1403343

I'd suspect crash is SPICE related.
Once using CLI similar to David's, I've managed to get locally:

  (process:101527): Spice-WARNING **: display-channel.c:2431:display_channel_validate_surface: canvas address is   0x5654ed415b08 for 0 (and is NULL)
  (process:101527): Spice-WARNING **: display-channel.c:2432:display_channel_validate_surface: failed on 0

but it didn't get to 'display_channel_update: condition ... failed' point and it didn't crash.
CLI was:

/usr/libexec/qemu-kvm -m 2048M -M pc,accel=kvm -smp 4 -drive if=none,id=cd,readonly=on,file=ubuntu-16.10-desktop-amd64.iso -device ide-cd,drive=cd -vga qxl -spice port=5900,password=12345

my env:
server:
qemu-kvm-rhev-2.10.0-11.el7.x86_64
spice-server-0.14.0-2.el7.x86_64
spice-protocol-0.12.13-2.el7.noarch
spice-glib-0.34-2.el7.x86_64
spice-gtk3-0.34-2.el7.x86_64

client:
virt-viewer-5.0-2.fc26.x86_64
spice-server-0.14.0-1.fc26.x86_64
spice-vdagent-0.17.0-2.fc26.x86_64
spice-gtk3-0.34-1.fc26.x86_64
spice-glib-0.34-1.fc26.x86_64

CCing Christophe and Gerd, perhaps they would have a better idea where to start with this.

As the reporter of #1403343 , just for the record, I'll note that one is still happening in Fedora openQA testing. Typically out of every ~50 tests which run with qxl as the video driver, 1 or 2 will crash this way. All I can do is restart them. (I should actually tweak our openQA test restarter plugin to restart them automatically, I guess...)

Upstream Commit 5bd5c27c7d284d01477c5cc022ce22438c46bf9f might be relevant (as well as for bug 1403343)

commit 5bd5c27c7d284d01477c5cc022ce22438c46bf9f
Author: Gerd Hoffmann <kraxel>
Date:   Fri Apr 27 13:55:28 2018 +0200

    qxl: fix local renderer crash
    
    Make sure we only ask the spice local renderer for display updates in
    case we have a valid primary surface.  Without that spice is confused
    and throws errors in case a display update request (triggered by
    screendump for example) happens in parallel to a mode switch and hits
    the race window where the old primary surface is gone and the new isn't
    establisted yet.

Thanks for the pointer, Bandan! I'll test that out for my case (1403343).

Hi Adma,
Could you help check bz 1567733 ? It already be fixed recently, may be they are same problem. Thanks!

Hi, Yanan! Sorry, I'm not sure what you mean. I didn't file this bug or bz 1567733 and I can't reproduce either of those two precisely, so I can't say whether either of those are fixed. The bug I filed is bz 1403343 , and I can tell you that one *is* fixed with recent qemu - I recently updated the bug to say so, and closed it. The fix for that issue was in qemu 2.11.2 and 2.12.0.

Thanks!

So, no reliable reproducer but we can see that logs including the Spice-CRITICAL one from https://bugzilla.redhat.com/show_bug.cgi?id=1403343#c0 is the same pointed out in comment #8.
Commit mentioned in comment #10 seems to have fixed the issue for bug 1403343. Commit log also mentions a race which would explain why isn't easy to reproduce it.

Full commit log actually inclueds 'Fixes: https://bugzilla.redhat.com//show_bug.cgi?id=1567733' which is in qemu-kvm-rhev-2.12.0-6.el7

Fix should also be present in qemu-kvm-1.5.3-9.el7

I'm closing this as CURRENT_RELEASE, please reopen if you can reproduce with any or above version of those qemu.