Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1515730 - qemu-kvm killed by SIGABRT while seamless tunnelled migration with virt-viewer opened
Summary: qemu-kvm killed by SIGABRT while seamless tunnelled migration with virt-viewe...
Keywords:
Status: CLOSED DUPLICATE of bug 1540919
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: spice
Version: 7.5
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Default Assignee for SPICE Bugs
QA Contact: SPICE QE bug list
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-21 09:39 UTC by yanqzhan@redhat.com
Modified: 2018-03-23 16:43 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-23 16:43:08 UTC


Attachments (Terms of Use)
fullbacktrace_qemu_libvirtd (deleted)
2017-11-21 11:56 UTC, yanqzhan@redhat.com
no flags Details

Description yanqzhan@redhat.com 2017-11-21 09:39:29 UTC
Description of problem:
qemu-kvm killed by SIGABRT while seamless tunnelled migration with virt-viewer opened

Version-Release number of selected component (if applicable):
spice-server-0.14.0-2.el7.x86_64
spice-gtk3-0.34-2.el7.x86_64
qemu-kvm-rhev-2.10.0-6.el7.x86_64
libvirt-3.9.0-2.el7.x86_64

How reproducible:
about 10%

Steps to Reproduce:
1.Prepare a vm with GUI with xml below, set spice="0.0.0.0" in /etc/libvirt/qemu.conf and restart libvirtd.
<graphics type='spice' port='5900' autoport='no' keymap='en-us'/>

2.open "virt-viewer V-GUI" or "remote-viewer spice://$source_ip:5900" to do some operations in guest os.

3.migrate to target and migrate back for several times:
# for i in {1..60}; do virsh migrate V-GUI qemu+ssh://ibm-x36***/system --live --p2p --tunnelled --unsafe --verbose;ssh ibm-x36***  virsh migrate V-GUI --live qemu+ssh://ibm-x38***/system --p2p --tunnelled --verbose --unsafe;done
Migration: [100 %]
Migration: [100 %]
...
Migration: [100 %]error: stream had I/O failure

4. # abrt-cli list
id 65f82047decde2b8b2a19c5b8a20e2669a1a7413
reason:         qemu-kvm killed by SIGABRT
time:           Fri 17 Nov 2017 06:01:41 AM EST
cmdline:        /usr/libexec/qemu-kvm -name guest=V-GUI,...-spice port=5900,addr=0.0.0.0,disable-ticketing,seamless-migration=on -k en-us -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 ... -msg timestamp=on
package:        qemu-kvm-rhev-2.10.0-6.el7
uid:            107 (qemu)
count:          8
Directory:      /var/spool/abrt/ccpp-2017-11-17-06:01:41-23355
Run 'abrt-cli report /var/spool/abrt/ccpp-2017-11-17-06:01:41-23355' for creating a case in Red Hat Customer Portal

5.(gdb) bt
#0  0x00007f6535a91227 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f6535a92918 in __GI_abort () at abort.c:90
#2  0x00007f6537c1645c in spice_logv (log_domain=0x7f6537c87311 "Spice", args=0x7f64e29fe520, 
    format=0x7f6537c8e51b "slot_id %d too big, addr=%lx", function=0x7f6537c8e650 <__FUNCTION__.15662> "memslot_get_virt", 
    strloc=0x7f6537c8e538 "memslot.c:111", log_level=G_LOG_LEVEL_CRITICAL) at log.c:183
#3  spice_log (log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, strloc=strloc@entry=0x7f6537c8e538 "memslot.c:111", 
    function=function@entry=0x7f6537c8e650 <__FUNCTION__.15662> "memslot_get_virt", 
    format=format@entry=0x7f6537c8e51b "slot_id %d too big, addr=%lx") at log.c:196
#4  0x00007f6537bdd4b6 in memslot_get_virt (info=info@entry=0x55b284059750, addr=addr@entry=5764607523034234880, 
    add_size=add_size@entry=20, group_id=group_id@entry=1, error=error@entry=0x7f64e29fe694) at memslot.c:111
#5  0x00007f6537be5c47 in red_get_data_chunks_ptr (slots=slots@entry=0x55b284059750, group_id=group_id@entry=1, 
    memslot_id=80, red=red@entry=0x7f64e29fe6f0, qxl=0x7f64e8352016) at red-parse-qxl.c:145
#6  0x00007f6537be82ee in red_get_cursor (addr=72057594060283904, red=0x55b28617c5c0, group_id=1, slots=0x55b284059750)
    at red-parse-qxl.c:1440
#7  red_get_cursor_cmd (slots=slots@entry=0x55b284059750, group_id=1, red=red@entry=0x55b28617c5a0, addr=<optimized out>)
    at red-parse-qxl.c:1481
#8  0x00007f6537bf8cdf in red_process_cursor_cmd (worker=worker@entry=0x55b2840596c0, ext=ext@entry=0x55b284b5a018)
    at red-worker.c:111
#9  0x00007f6537bf8e7b in loadvm_command (ext=0x55b284b5a018, worker=0x55b2840596c0) at red-worker.c:980
#10 handle_dev_loadvm_commands (opaque=0x55b2840596c0, payload=<optimized out>) at red-worker.c:1002
#11 0x00007f6537bc529d in dispatcher_handle_single_read (dispatcher=0x55b2854b68c0) at dispatcher.c:284
#12 dispatcher_handle_recv_read (dispatcher=0x55b2854b68c0) at dispatcher.c:304
#13 0x00007f6537bcbaab in watch_func (source=<optimized out>, condition=<optimized out>, data=0x55b2868fa2a0)
    at event-loop.c:128
#14 0x00007f65376d18f9 in g_main_dispatch (context=0x55b28401f130) at gmain.c:3146
#15 g_main_context_dispatch (context=context@entry=0x55b28401f130) at gmain.c:3811
#16 0x00007f65376d1c58 in g_main_context_iterate (context=0x55b28401f130, block=block@entry=1, dispatch=dispatch@entry=1, 
    self=<optimized out>) at gmain.c:3884
---Type <return> to continue, or q <return> to quit---
#17 0x00007f65376d1f2a in g_main_loop_run (loop=0x55b2861d9e00) at gmain.c:4080
#18 0x00007f6537bf9f2a in red_worker_main (arg=0x55b2840596c0) at red-worker.c:1372
#19 0x00007f6535e2fe25 in start_thread (arg=0x7f64e29ff700) at pthread_create.c:308
#20 0x00007f6535b599cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113


Actual results:
As the step3,migration failed, and as the step4, qemu crashed.

Expected results:
Should migrate successfully without error, and qemu-kvm should not be killed.

Additional info:
1. qemu.log:
(process:28803): Spice-CRITICAL **: memslot.c:111:memslot_get_virt: slot_id 32 too big, addr=2000000000000000
2017-11-21 06:35:37.859+0000: shutting down, reason=crashed

2. libvirtd.log:
2017-11-21 06:35:37.859+0000: 7042: debug : qemuMigrationErrorSave:5832 : Saving incoming migration error for domain V-GUI: internal error: qemu unexpectedly closed the monitor: 2017-11-21T06:35:21.468873Z qemu-kvm: -chardev pty,id=charserial0: char device redirected to /dev/pts/4 (label charserial0)


3.. Virt-viewer msg:
# virt-viewer V-GUI

(virt-viewer:19562): Gtk-WARNING **: Allocating size to SpiceDisplay 0x557b32600350 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(virt-viewer:19562): GSpice-CRITICAL **: clipboard_got_from_guest: assertion 'selection == ri->selection' failed

(virt-viewer:19562): GSpice-CRITICAL **: clipboard_got_from_guest: assertion 'selection == ri->selection' failed

(virt-viewer:19562): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(virt-viewer:19562): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(virt-viewer:19562): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(virt-viewer:19562): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(virt-viewer:19562): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(virt-viewer:19562): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(virt-viewer:19562): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(virt-viewer:19562): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(virt-viewer:19562): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(virt-viewer:19562): GSpice-CRITICAL **: clipboard_got_from_guest: assertion 'selection == ri->selection' failed

(virt-viewer:19562): GSpice-CRITICAL **: clipboard_got_from_guest: assertion 'selection == ri->selection' failed

Comment 2 yanqzhan@redhat.com 2017-11-21 11:56:08 UTC
Created attachment 1356628 [details]
fullbacktrace_qemu_libvirtd

Refer to logs in attachment:
full backtrace: my-gdb.txt
qemu log: my-V-GUI.log
libvirtd log: my-libvirtd.log-cut1.tar.gz

btw, the virt-viewer version used is virt-viewer-5.0-9.el7.x86_64.

Comment 3 Christophe Fergeau 2017-11-21 15:21:02 UTC
Which guest OS are you using? I've tried to reproduce, but haven't succeeded so far.
You are not using --graphicsuri on your virsh migrate commandline? Without it, virt-viewer loses connection to the VM and closes its window here.

Comment 4 Christophe Fergeau 2017-11-21 15:23:28 UTC
Since you have a setup where you can reproduce, do you think it would be possible to get access to it?

Comment 5 yanqzhan@redhat.com 2017-11-22 04:23:31 UTC
(In reply to Christophe Fergeau from comment #3)
> Which guest OS are you using? I've tried to reproduce, but haven't succeeded
> so far.
> You are not using --graphicsuri on your virsh migrate commandline? Without
> it, virt-viewer loses connection to the VM and closes its window here.

Hi, seamless spice configuration in the step1 is enough to keep virt-viewer connecting while migration. (spice="0.0.0.0" should be set on both sides)

And some new additional output below, hope be helpful:
# for i in {1..60}; do virsh migrate V-GUI qemu+ssh://ibm-x36***/system --live --unsafe --verbose;ssh ibm-x36***  virsh migrate V-GUI --live qemu+ssh://ibm-x38***/system --verbose --unsafe;done
Migration: [100 %]
...
Migration: [100 %]error: internal error: qemu unexpectedly closed the monitor: 2017-11-22T04:11:44.315605Z qemu-kvm: -chardev pty,id=charserial0: char device redirected to /dev/pts/3 (label charserial0)
main_channel_link: add main channel client
red_qxl_set_cursor_peer: 
inputs_connect: inputs channel client create
red_qxl_loadvm_commands: 
id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0, delta 0
id 1, group 1, virt start 7f476d600000, virt end 7f47715fe000, generation 0, delta 7f476d600000
id 2, group 1, virt start 7f4769200000, virt end 7f476d200000, generation 0, delta 7f4769200000

(process:15502): Spice-CRITICAL **: memslot.c:111:memslot_get_virt: slot_id 16 too big, addr=1000000000000000

Comment 8 yanqzhan@redhat.com 2017-11-28 02:55:43 UTC
Hi Christophe, 

The machine is used for other urgent testing now. I can re-prepare the env after that testing, then provide information for you. Pls wait a few days. 

Thx

Comment 9 Dr. David Alan Gilbert 2017-12-04 09:48:28 UTC
Feels very much like bz 1421788 (and bz 1290039 and bz 1210536)  which we hoped dbb5fb8d3519130559b10fa4e1395e4486c633f8  would fix; but we've never had a reliable reproducer.

Comment 10 yanqzhan@redhat.com 2017-12-14 03:04:25 UTC
I can still reproduce this issue on current version:
kernel-3.10.0-820.el7.x86_64
spice-server-0.14.0-2.el7.x86_64
spice-gtk3-0.34-2.el7.x86_64
virt-viewer-5.0-10.el7.x86_64
libvirt-3.9.0-6.virtcov.el7.x86_64
qemu-kvm-rhev-2.10.0-12.el7.x86_64

Steps:
[Terminal 1]# virsh destroy V-GUI; sleep 3; virsh start V-GUI;sleep 6;for i in {1..20}; do virsh migrate V-GUI qemu+ssh://ibm-x36***/system --live --p2p --tunnelled --unsafe --verbose;ssh ibm-x36***  virsh migrate V-GUI --live qemu+ssh://10.7***/system --p2p --tunnelled --verbose --unsafe;done

[Terminal 2]Open "#remote-viewer spice://10.7***:5900 in another terminal", login guest os, do some operations such as open files, frequently click on each dir, and open firefox, add some tabs, etc

Results:
[Terminal 1]
error: Failed to destroy domain V-GUI
error: Requested operation is not valid: domain is not running

Domain V-GUI started

Migration: [100 %]
Migration: [100 %]
Migration: [100 %]
Migration: [100 %]
Migration: [100 %]error: stream had I/O failure

error: failed to get domain 'V-GUI'
error: Domain not found: no domain with matching name 'V-GUI'

[Terminal 2]
(remote-viewer:2119): Gtk-WARNING **: Allocating size to SpiceDisplay 0x55f3aa6803e0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(remote-viewer:2119): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:2119): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:2119): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:2119): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:2119): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:2119): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:2119): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:2119): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:2119): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

[on source or target host]# abrt-cli list
id f6a9f44958a45942df322f00f4f1f1c52a0d75b4
reason:         qemu-kvm killed by SIGABRT
time:           Wed 13 Dec 2017 09:40:09 PM EST
cmdline:        /usr/libexec/qemu-kvm -name guest=V-GUI,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-95-V-GUI/master-key.aes -machine pc-i440fx-rhel7.5.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Westmere,vme=on,pclmuldq=on,x2apic=on,hypervisor=on,arat=on -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid be1530bb-a0ba-44e0-aa8f-6f5d2e0ddf81 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-95-V-GUI/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/s3-qe-team/yanqzhan/V7.4-GUI-released.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:c7:cc:77,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-95-V-GUI/org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=0.0.0.0,disable-ticketing,seamless-migration=on -k en-us -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -incoming defer -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on
package:        qemu-kvm-rhev-2.10.0-12.el7
uid:            107 (qemu)
Directory:      /var/spool/abrt/ccpp-2017-12-13-21:40:09-29892
Run 'abrt-cli report /var/spool/abrt/ccpp-2017-12-13-21:40:09-29892' for creating a case in Red Hat Customer Portal

Very low probability. I can lend you the env, but you might try more times.

Comment 14 yanqzhan@redhat.com 2018-01-03 08:43:42 UTC
Also reproduced when cross migration from rhel7.5 to rhel7.3.
I start a rhel7.3 guest on rhel7.3 host, migrate to rhel7.5 host then migrate back. The issue occurred sometimes when migrate back: target qemu killed.

1. Pkgs version:
rhel7.5 host:
kernel-3.10.0-823.el7.x86_64
spice-server-0.14.0-2.el7.x86_64
spice-gtk3-0.34-2.el7.x86_64
virt-viewer-5.0-10.el7.x86_64
libvirt-3.9.0-6.el7.x86_64
qemu-kvm-rhev-2.10.0-13.el7.x86_64

rhel7.3 host:
kernel-3.10.0-514.36.3.el7.x86_64
spice-server-0.12.4-20.el7_3.1.x86_64
spice-gtk3-0.31-6.el7_3.2.x86_64
virt-viewer-2.0-12.el7.x86_64
libvirt-2.0.0-10.el7_3.10.x86_64
qemu-kvm-rhev-2.6.0-28.el7_3.15.x86_64

2. Cmd and errors output sometimes:
Migration failed, rhel7.3 host qemu killed by ABRT, guest shutting down then restored on rhel7.5host, virt-viewer disconnect.
[rhel7.5-host]# virsh migrate V7.3-full qemu+ssh://rhel7.3-host/system --live --p2p --tunnelled --unsafe --verbose
Migration: [100 %]error: Cannot recv data: Ncat: Connection reset by peer.: Connection reset by peer
or:
Migration: [100 %]error: End of file while reading data: Ncat: Connection reset by peer.: Input/output error
or:
Migration: [100 %]error: internal error: client socket is closed

3. ABRT coredump:
[rhel7.3 host]# abrt-cli ls
id 65e946b06539cbda3acb95c2f5e50f619c1f377a
reason:         qemu-kvm killed by SIGABRT
time:           Wed 03 Jan 2018 02:22:50 AM EST
cmdline:        /usr/libexec/qemu-kvm -name guest=V7.3-full,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-20-V7.3-full/master-key.aes -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off,vmport=on,mem-merge=off -cpu Penryn,+kvm_pv_unhalt,hv_crash,pmu=off -bios /usr/share/seabios/bios.bin -m size=512000k,slots=16,maxmem=2124800k ... -device pvpanic,ioport=1285 -msg timestamp=on
package:        qemu-kvm-rhev-2.6.0-28.el7_3.15
uid:            107 (qemu)
count:          1
Directory:      /var/spool/abrt/ccpp-2018-01-03-02:22:50-4490
Run 'abrt-cli report /var/spool/abrt/ccpp-2018-01-03-02:22:50-4490' for creating a case in Red Hat Customer Portal

(gdb) bt
#0  0x00007fa8e3b831d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007fa8e3b848c8 in __GI_abort () at abort.c:90
#2  0x00007fa8e599261c in spice_logv (log_domain=0x7fa8e5a0fd5d "SpiceWorker", log_level=SPICE_LOG_LEVEL_ERROR, 
    strloc=0x7fa8e5a10390 "red_worker.c:5128", function=0x7fa8e5a12eb0 <__FUNCTION__.34449> "qxl_process_cursor", 
    format=0x7fa8e5a10376 "invalid cursor command %u", args=args@entry=0x7fa880dfc660) at log.c:109
#3  0x00007fa8e5992775 in spice_log (log_domain=log_domain@entry=0x7fa8e5a0fd5d "SpiceWorker", 
    log_level=log_level@entry=SPICE_LOG_LEVEL_ERROR, strloc=strloc@entry=0x7fa8e5a10390 "red_worker.c:5128", 
    function=function@entry=0x7fa8e5a12eb0 <__FUNCTION__.34449> "qxl_process_cursor", 
    format=format@entry=0x7fa8e5a10376 "invalid cursor command %u") at log.c:123
#4  0x00007fa8e5956270 in qxl_process_cursor (worker=worker@entry=0x7fa9030bc000, cursor_cmd=cursor_cmd@entry=0x7fa8ff126ad0, 
    group_id=<optimized out>) at red_worker.c:5128
#5  0x00007fa8e596380f in handle_dev_loadvm_commands (opaque=0x7fa9030bc000, payload=<optimized out>) at red_worker.c:11923
#6  0x00007fa8e594d573 in dispatcher_handle_single_read (dispatcher=0x7fa8ff150f28) at dispatcher.c:139
#7  dispatcher_handle_recv_read (dispatcher=0x7fa8ff150f28) at dispatcher.c:162
#8  0x00007fa8e5971625 in red_worker_main (arg=<optimized out>) at red_worker.c:12278
#9  0x00007fa8e3f16dc5 in start_thread (arg=0x7fa880dff700) at pthread_create.c:308
#10 0x00007fa8e3c4576d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

4.Log info:
rhel7.3 qemu log:
inputs_detach_tablet: 
red_dispatcher_loadvm_commands: 
id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0, delta 0
id 1, group 1, virt start 7fd423800000, virt end 7fd4277fe000, generation 0, delta 7fd423800000
id 2, group 1, virt start 7fd41b400000, virt end 7fd423400000, generation 0, delta 7fd41b400000
((null):2625): Spice-CRITICAL **: red_memslots.c:123:get_virt: slot_id 176 too big, addr=b000000000000000
2018-01-03 07:06:47.870+0000: shutting down
2018-01-03 07:20:20.560+0000: starting up ...

rhel7.5 libvirtd.log:
2018-01-03 07:23:20.491+0000: 73458: error : virNetSocketWriteWire:1852 : Cannot write data: Broken pipe
2018-01-03 07:23:20.494+0000: 72618: error : virNetClientSendInternal:2123 : internal error: client socket is closed
2018-01-03 07:23:20.564+0000: 72618: error : virNetClientSendInternal:2123 : internal error: client socket is closed
2018-01-03 07:23:20.564+0000: 72618: error : virNetClientSendInternal:2123 : internal error: client socket is closed

5. spice error
# remote-viewer spice://rhel7.5or7.3-host:5900
(remote-viewer:4060): GSpice-WARNING **: Failed to get playback async volume info: Stream not found by pulse

(remote-viewer:4060): GSpice-WARNING **: Failed to get record async volume info: Stream not found by pulse

(remote-viewer:4060): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:4060): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:4060): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:4060): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:4060): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:4060): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:4060): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:4060): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:4060): GSpice-CRITICAL **: try_keyboard_grab: assertion 'gtk_widget_is_focus(widget)' failed

(remote-viewer:4060): GSpice-CRITICAL **: set_cursor: assertion 'scursor->data_size != 0' failed

Comment 15 Christophe Fergeau 2018-03-23 16:43:08 UTC
(In reply to Dr. David Alan Gilbert from comment #9)
> Feels very much like bz 1421788 (and bz 1290039 and bz 1210536)  which we
> hoped dbb5fb8d3519130559b10fa4e1395e4486c633f8  would fix; but we've never
> had a reliable reproducer.

I believe we introduced a slight variation around these bugs that you listed in spice-server 0.14.0, see https://bugzilla.redhat.com/show_bug.cgi?id=1540919#c24
I'll mark this one as a duplicate.

*** This bug has been marked as a duplicate of bug 1540919 ***


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