spice issueshttps://gitlab.freedesktop.org/groups/spice/-/issues2021-08-31T08:00:31Zhttps://gitlab.freedesktop.org/spice/spice-gtk/-/issues/151spicy connect to vm that has usbredir device will crash on mac2021-08-31T08:00:31Zlixiangspicy connect to vm that has usbredir device will crash on macHi,I connect to vm with spicy client(v0.37),if the vm has usb redirdev,the client crashed during connecting,I remove usb redirdev,everything work fine.Anybody know why?
# vm xml...
```
<redirdev bus='usb' type='spicevmc'>
<al...Hi,I connect to vm with spicy client(v0.37),if the vm has usb redirdev,the client crashed during connecting,I remove usb redirdev,everything work fine.Anybody know why?
# vm xml...
```
<redirdev bus='usb' type='spicevmc'>
<alias name='redir0'/>
<address type='usb' bus='0' port='1'/>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
<alias name='redir1'/>
<address type='usb' bus='0' port='2'/>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
<alias name='redir2'/>
<address type='usb' bus='0' port='3'/>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
<alias name='redir3'/>
<address type='usb' bus='0' port='4'/>
</redirdev>
```
#log...
```
(spicy:19256): GSpice-DEBUG: 15:39:08.847: ../src/channel-display.c:1069 display-2:1: spice_display_channel_up: cache_size 83886080, glz_window_size 25161728 (bytes)
(spicy:19256): GSpice-DEBUG: 15:39:08.847: ../src/spice-channel.c:1298 usbredir-9:3: channel up, state 3
(spicy:19256): GSpice-DEBUG: 15:39:08.847: ../src/channel-usbredir.c:619 usbredir-9:3: usbredirparser: Peer version: qemu usb-redir guest 2.11.0, using 64-bits ids
spicy(19256,0x1000f7e00) malloc: *** error for object 0x1025f4030: pointer being freed was not allocated
spicy(19256,0x1000f7e00) malloc: *** set a breakpoint in malloc_error_break to debug
Process 19256 stopped
```
# stack....
```
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
* frame #0: 0x00007fff2057292e libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00007fff205a15bd libsystem_pthread.dylib`pthread_kill + 263
frame #2: 0x00007fff204f6411 libsystem_c.dylib`abort + 120
frame #3: 0x00007fff203d61f5 libsystem_malloc.dylib`malloc_vreport + 548
frame #4: 0x00007fff203d934a libsystem_malloc.dylib`malloc_report + 151
frame #5: 0x0000000101974d4c libusbredirparser.1.dylib`usbredirparser_do_read + 1852
frame #6: 0x000000010018fa7f libspice-client-glib-2.0.8.dylib`usbredir_handle_msg(c=0x0000000102881ca0, in=0x00000001025f4920) at channel-usbredir.c:881:13
frame #7: 0x000000010019917d libspice-client-glib-2.0.8.dylib`spice_channel_handle_msg(channel=0x0000000102881ca0, msg=0x00000001025f4920) at spice-channel.c:3100:5
frame #8: 0x0000000100195e88 libspice-client-glib-2.0.8.dylib`spice_channel_recv_msg(channel=0x0000000102881ca0, msg_handler=(libspice-client-glib-2.0.8.dylib`spice_channel_handle_msg at spice-channel.c:3089), data=0x0000000000000000) at spice-channel.c:2112:5
frame #9: 0x00000001001984c4 libspice-client-glib-2.0.8.dylib`spice_channel_iterate_read(channel=0x0000000102881ca0) at spice-channel.c:2350:13
frame #10: 0x000000010019b5c9 libspice-client-glib-2.0.8.dylib`spice_channel_iterate(channel=0x0000000102881ca0) at spice-channel.c:2388:9
frame #11: 0x000000010019a27a libspice-client-glib-2.0.8.dylib`spice_channel_coroutine(data=0x0000000102881ca0) at spice-channel.c:2676:12
frame #12: 0x00000001001c9e6a libspice-client-glib-2.0.8.dylib`coroutine_trampoline(cc=0x00000001028814d8) at coroutine_ucontext.c:63:13
frame #13: 0x00000001001c9b99 libspice-client-glib-2.0.8.dylib`continuation_trampoline(i0=42472664, i1=1) at continuation.c:55:2
frame #14: 0x00007fff205ea46f libsystem_platform.dylib`_ctx_start + 11
```https://gitlab.freedesktop.org/spice/linux/vd_agent/-/issues/35spice-vdagentd does not work on KDE Plasma2023-11-01T23:05:51ZDUO Labsspice-vdagentd does not work on KDE PlasmaRelated to #27. See also https://bugs.kde.org/show_bug.cgi?id=472622.
On KDE Plasma on X11,`spice-vdagentd` is started automatically when you log in. However, if you try to copy you get `UID mismatch: UID=1001 PID=636 suid=4294967295`.
...Related to #27. See also https://bugs.kde.org/show_bug.cgi?id=472622.
On KDE Plasma on X11,`spice-vdagentd` is started automatically when you log in. However, if you try to copy you get `UID mismatch: UID=1001 PID=636 suid=4294967295`.
`spice-vdagent` (the user daemon) is dead. If you try to start it manually with `spice-vdagent -d -x`, you get
```plaintext
spice-vdagent[17777]: vdagent started
spice-vdagent[17777]: 0xaaab02cf2d30 connected to /run/spice-vdagentd/spice-vdagent-sock
spice-vdagent[17777]: vdagent_display_create: net_wm_name="KWin", has icons=0
spice-vdagent[17777]: display: failed to call GetCurrentState from mutter over DBUS
spice-vdagent[17777]: error message: Cannot invoke method; proxy is for the well-known name org.gnome.Mutter.DisplayConfig without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
spice-vdagent[17777]: No guest output map, using output index as display id
spice-vdagent[17777]: Sending guest screen resolutions to vdagentd:
spice-vdagent[17777]: display_id=0 - 1280x800+0+0
spice-vdagent[17777]: 0xaaab02cf2d30 sent guest xorg resolution, arg1: 1280, arg2: 800, size 20
spice-vdagent[17777]: 0xaaab02cf2d30 disconnected
```
Interestingly, if I install xdg-desktop-portal-gtk/vte3 and reboot, clipboard sync works as expected. However, if I reboot again after, it stops working again.
All other DEs I have tried work as expectedhttps://gitlab.freedesktop.org/spice/spice-streaming-agent/-/issues/6spice-streaming-agent: UNKNOWN msg of type 02022-05-19T03:27:31ZSoveaspice-streaming-agent: UNKNOWN msg of type 0Host: QEMU(6.1.0) Spice-Protocol(the latest/v0.12.15) Spice(the latest/v0.14) Spice-GTK(the latest)
VM: Spice-Protocol(the latest/v0.14.0) spice-streaming-agent(the latest/v0.3)
qemu-system-x86_64 -vga qxl -m 4096 -spice port=11000,t...Host: QEMU(6.1.0) Spice-Protocol(the latest/v0.12.15) Spice(the latest/v0.14) Spice-GTK(the latest)
VM: Spice-Protocol(the latest/v0.14.0) spice-streaming-agent(the latest/v0.3)
qemu-system-x86_64 -vga qxl -m 4096 -spice port=11000,tls-port=20001,disable-ticketing=on,x509-dir=/home/sovea/dev/rsa_cert_files,tls-channel=main,tls-channel=inputs -drive file=/home/sovea/dev/img-instance/ubuntu.img -smp cores=2,threads=2,sockets=1 -enable-kvm -cpu host -device virtio-serial -device virtserialport,nr=1,chardev=charchannel1,name=org.spice-space.stream.0 -chardev spicevmc,id=charchannel1,name=vdagent -nic user,hostfwd=tcp:127.0.0.1:2222-:22
When I started scipy in the Host and spice-streaming-agent in VM, get error "spice-streaming-agent: UNKNOWN msg of type 0", QEMU get "main_channel_handle_message: agent start".https://gitlab.freedesktop.org/spice/spice/-/issues/84spice-server: error: visibility does not match previous declaration2024-01-31T05:54:23ZKupietoolsspice-server: error: visibility does not match previous declaration```
---> Building spice-server
Error: Failed to build spice-server: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_spice-server/s...```
---> Building spice-server
Error: Failed to build spice-server: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_spice-server/spice-server/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there
is a bug.
Error: Processing of port spice-server failed
```
The mentioned main.log is enormous and searching for errors is tough.
I did find a failed make command in the log and ran it manually, and got:
```
inputs-channel.cpp:467:1: error: visibility does not match previous declaration
SPICE_GNUC_VISIBLE int spice_server_kbd_leds(SpiceKbdInstance *sin, int leds)
^
./utils.h:28:44: note: expanded from macro 'SPICE_GNUC_VISIBLE'
#define SPICE_GNUC_VISIBLE __attribute__ ((visibility ("default")))
^
./push-visibility.h:19:13: note: previous attribute is here
#pragma GCC visibility push(hidden)
```
I'm unable to install Colima because of this. MacBook Pro running Mojave 10.14.6. Thanks.https://gitlab.freedesktop.org/spice/spice/-/issues/43Spice Seamless Migration Sequence issue2023-03-29T09:14:27Zucontacti ssSpice Seamless Migration Sequence issueI am trying to reproduce the seamless migration capability of the Spice Protocol. But I get this error from Inputs and Display Channel when I tried to send back the migration data (server closes those sockets).
```
2020-05-07T10:09:48.74...I am trying to reproduce the seamless migration capability of the Spice Protocol. But I get this error from Inputs and Display Channel when I tried to send back the migration data (server closes those sockets).
```
2020-05-07T10:09:48.746002Z qemu-system-x86_64: warning: Spice: inputs:0 (0x558ddee468a0): unexpected
2020-05-07T10:09:48.853621Z qemu-system-x86_64: warning: Spice: display:0 (0x558ddee45940): unexpected
```
Is there any prerequisite before sending migration data to the new server?
This is Qemu log for Destination Server:
```
2020-05-07 11:18:22.064+0000: starting up libvirt version: 6.0.0, package: 6 (Guido Günther <agx@sigxcpu.org> Wed, 08 Apr 2020 17:04:11 +0200), qemu version: 4.2.0Debian 1:4.2-7, kernel: 5.4.0-4-amd64, hostname: cersei.tarja.server
LC_ALL=C \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
HOME=/var/lib/libvirt/qemu/domain-73-migration-6011 \
XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-73-migration-6011/.local/share \
XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-73-migration-6011/.cache \
XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-73-migration-6011/.config \
QEMU_AUDIO_DRV=spice \
/usr/bin/qemu-system-x86_64 \
-name guest=migration-6011,debug-threads=on \
-S \
-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-73-migration-6011/master-key.aes \
-machine pc-q35-4.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off \
-cpu Cascadelake-Server,ss=on,vmx=on,hypervisor=on,tsc-adjust=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,xsaves=on,ibpb=on,amd-ssbd=on,rdctl-no=on,ibrs-all=on,skip-l1dfl-vmentry=on,mds-no=on,mpx=off \
-m 2048 \
-overcommit mem-lock=off \
-smp 2,sockets=2,cores=1,threads=1 \
-uuid 05422bab-d384-4be0-81a9-496fa3632443 \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=33,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 ICH9-LPC.disable_s3=1 \
-global ICH9-LPC.disable_s4=1 \
-boot strict=on \
-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \
-device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x1d.0x7 \
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x1d \
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x1d.0x1 \
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x1d.0x2 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x0 \
-blockdev '{"driver":"file","filename":"/srv/libvirt/images/clone-dummy-clone.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null}' \
-device virtio-blk-pci,scsi=off,bus=pci.3,addr=0x0,drive=libvirt-2-format,id=virtio-disk0,bootindex=1 \
-device ide-cd,bus=ide.0,id=sata0-0-0 \
-netdev tap,fd=35,id=hostnet0,vhost=on,vhostfd=36 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:51:68:13,bus=pci.1,addr=0x0 \
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev socket,id=charchannel0,fd=38,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=6011,tls-port=7011,addr=0.0.0.0,x509-dir=/etc/pki/libvirt-spice,image-compression=auto_glz,streaming-video=all,seamless-migration=on \
-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 \
-device ich9-intel-hda,id=sound0,bus=pcie.0,addr=0x1b \
-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.4,addr=0x0 \
-object rng-random,id=objrng0,filename=/dev/urandom \
-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.5,addr=0x0 \
-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
char device redirected to /dev/pts/0 (label charserial0)
2020-05-07T11:18:22.202067Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12]
2020-05-07T11:18:22.202160Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13]
2020-05-07T11:18:22.204015Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12]
2020-05-07T11:18:22.204029Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13]
2020-05-07T11:18:27.487594Z qemu-system-x86_64: warning: Spice: inputs:0 (0x561530d708a0): unexpected
2020-05-07T11:18:27.529391Z qemu-system-x86_64: warning: Spice: display:0 (0x561530d6f940): unexpected
2020-05-07T11:18:27.529585Z qemu-system-x86_64: warning: GLib-GObject: invalid unclassed pointer in cast to 'RedChannelClient'
```
I trigger migration using virt-manager with Mode: Direct and Allow unsafe: True and Temporary move: False
Qemu version: 4.2.0
spice server version: 0.14.3-1
The same procedure works well without issue on other clients that use Spice-Gtk (ex. Remmina) but for me, the same thing closes Inputs and Display Channel after I send migration data to the destination server.https://gitlab.freedesktop.org/spice/spice/-/issues/31Spice protocol documentation2020-03-05T18:27:47ZGeoffrey McRaeSpice protocol documentationThe spice protocol draft on the website is horrendously out of date, contains many spelling errors and is missing some very important technical information such as:
* `Red` and `RED` are now `Spice` and `SPICE` respectively.
* There is...The spice protocol draft on the website is horrendously out of date, contains many spelling errors and is missing some very important technical information such as:
* `Red` and `RED` are now `Spice` and `SPICE` respectively.
* There is no hint that the common and channel caps in `SpiceLinkMess` are bitfields, the documentation reads as if these are simple vectors of values.
* The common and channel caps are not documented.
* There is no mention of the `SpiceMiniDataHeader`
As it is the only source of protocol documentation developers are forced to turn to the source code which fully takes advantage of GTK+. Due to the fact that understanding and learning the GTK+ API is critical to understanding the protocol specifics I would say that this is extremely poor.https://gitlab.freedesktop.org/spice/linux/vd_agent/-/issues/29spice not correctly handling cursor events at edge of guest screen2022-11-10T22:17:41Zbrainchildspice not correctly handling cursor events at edge of guest screen# Description
I have found that a Spice console does not necessarily function as expected for certain features of a modern desktop environment, with respect to handling cursor events at the screen edge.
I have tested in a configuration...# Description
I have found that a Spice console does not necessarily function as expected for certain features of a modern desktop environment, with respect to handling cursor events at the screen edge.
I have tested in a configuration of a guest and host both running the Cinnamon desktop environment under Linux Mint 21. I have discovered two sequences of events, supported by Cinnamon, relating to screen edge, that the Spice stack has not handled properly, in my observations.
The first problematic sequence of events is the one that invokes the tiling feature of the window manager. The intended behavior is that when a user moves a window to the edge of the screen, or precisely, when the user attempts to move the window past the edge, the window manager resizes the window to occupy the half of the screen fully bordering the target edge. In particular, once the cursor has been positioned at the screen edge but the drag operation has not yet been released, the window manager shades the target region (see [screen capture](/uploads/93d2967b102b5b022fd796fa8a1e14bc/Screenshot_from_2022-10-18_16-31-40.png)). However, when occurring through the Spice stack, the release event, which occurs after the cursor has passed beyond the edge of the client window, is never processed by the guest console. The intermediary state involving the shaded region remains until the client window is again engaged by the cursor. For the effect to work as desired, the client must monitor the drag operation that initiated inside of the client window, and propagate the release event to the guest.
The second sequence of events is the one related to the display of panels configured for "auto hide", such that they are meant to be revealed when the cursor places "pressure" on the edge of the screen where the panel is hiding. Similar to the first type of event, the pressure is not processed by the client such that the guest display system would behave according to its design.
Both problems persist when the client is operated on the full screen, the same as in a window.
# Environment
- **Host OS:** Linux Mint 21, kernel 6.0.1
- **Guest OS:** Linux Mint 21, kernel 5.15.0
- **Host Desktop:** Cinnamon 5.4.12
- **Guest Desktop:** Cinnamon 5.4.12
- **QEMU version:** 5.4.12
- **Spice client:** Virtual Machine Manager 4.0.0
- **Spice agent version:** 0.22.1-1https://gitlab.freedesktop.org/spice/spice/-/issues/68Spice LEDs get out of sync if guest doesn't act on CapsLock2022-03-14T09:09:52ZQuantumSpice LEDs get out of sync if guest doesn't act on CapsLockIn the commit ff9c8d4908e12db65a6cd2d61b4ed7b8174e6d78, the Spice server switched from the QEMU LED state to its own internal LED state. In the commit message, it says that:
> When the guest notifies its change, the modifiers_watch is su...In the commit ff9c8d4908e12db65a6cd2d61b4ed7b8174e6d78, the Spice server switched from the QEMU LED state to its own internal LED state. In the commit message, it says that:
> When the guest notifies its change, the modifiers_watch is supposed to fix any wrong state.
However, in that same commit, the `modifiers_watch` (which calls `key_modifiers_sender`), simply sends what the Spice server thinks is the modifier state:
```c
inputs_channel_push_keyboard_modifiers(inputs, inputs->modifiers);
```
(This is now converted to the C++ `inputs->push_keyboard_modifiers();` which calls `pipes_add(red::make_shared<RedKeyModifiersPipeItem>(modifiers));`, but does effectively the same thing.)
In fact, in the whole file, the only time we ever query the guest's state by calling `kbd_get_leds` is in `pipe_add_init`. As such, anytime the guest ignores the <kbd>CapsLock</kbd> for some reason, its LED state goes out of sync with what the Spice server thinks is the LED state.
We discovered this bug while debugging a [user-reported issue](https://github.com/gnif/LookingGlass/issues/974) in our Spice client. This user remapped the <kbd>CapsLock</kbd> key in the VM to <kbd>Escape</kbd>, which causes the guest to not toggle the CapsLock LED when the <kbd>CapsLock</kbd> key is pressed. However, the Spice server thinks the CapsLock LED is on. When the Spice client sends `SPICE_MSGC_INPUTS_KEY_MODIFIERS` without the CapsLock modifier, the Spice server generates a spurious <kbd>CapsLock</kbd> press in the guest to cancel out the CapsLock LED, which the server believes is on. In the user's case, this causes <kbd>Escape</kbd> to be pressed spuriously.
I suspect something similar happens with all the other modifier keys (e.g. <kbd>NumLock</kbd> and <kbd>ScrollLock</kbd>) when remapped.https://gitlab.freedesktop.org/spice/win32/spice-nsis/-/issues/6Spice Guest Tools Downloads are not versioned2021-10-15T08:13:21ZVictor TosoSpice Guest Tools Downloads are not versioned`Migrating issue from gitlab.com to gitlab.freedesktop.org`
`original author:`[Emmanuel Kasper](https://gitlab.com/EmmanuelKasper)
Instead of being a file by itself, it would help if the download link provided at
https://www.spice-spa...`Migrating issue from gitlab.com to gitlab.freedesktop.org`
`original author:`[Emmanuel Kasper](https://gitlab.com/EmmanuelKasper)
Instead of being a file by itself, it would help if the download link provided at
https://www.spice-space.org/download.html would resolve to the binary with version name, for instance
spice-guest-tools-0.132.exe.
VirtIO iso downloads at https://fedoraproject.org/wiki/Windows_Virtio_Drivers are like this, when clicking on https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso resolves to a versioned binary download.
Doing this depends on the configuration of the WebServer, I suppose the easiest way to do this would to create a hook script on the server which would actualize on the server a symlink from spice-guest-tools-latest.exe to spice-guest-tools-0.132/spice-guest-tools-0.132.exe after each upload.https://gitlab.freedesktop.org/spice/spice-gtk/-/issues/30spice-gtk / remote-viewer SSL verification behavior2018-06-03T10:21:41ZChristophe Fergeauspice-gtk / remote-viewer SSL verification behavior## Submitted by Christophe Fergau Fergau `@teuf`
Assigned to **Spice Bug List**
**[Link to original bug (#94063)](https://bugs.freedesktop.org/show_bug.cgi?id=94063)**
## Description
From https://bugzilla.redhat.com/show_bug.cgi?i...## Submitted by Christophe Fergau Fergau `@teuf`
Assigned to **Spice Bug List**
**[Link to original bug (#94063)](https://bugs.freedesktop.org/show_bug.cgi?id=94063)**
## Description
From https://bugzilla.redhat.com/show_bug.cgi?id=1305785
Description of problem:
spice-gtk (and thus remote-viewer) use OpenSSL to verify the SSL certificate used to encrypt the spice connection. It is possible to provide a trusted CA file or trusted CA certificate(s) in the remote-viewer configuration file (options "ca-file" and "ca").
Unfortunately, spice-gtk will only accept root certificates as trusted, it is therefor not possible to provide only the server or intermediate certificate when connecting. Accepting provided intermediate (or server) certificates would actually provide better security because of the more limited scope, as well as ease deployment in a non-self-signed setup: the usual work flow is to configure the chain up to but excluding the root certificate on the server side, if the server is also responsible for generating the configuration files, it needs to acquire and provide the correct root certificate via a separate mechanism.
Steps to Reproduce:
1. run a spice server instance configured with an intermediate and end certificate, but not the root
2. create a remote-viewer configuration file with ca="`<PEM encoded version of intermediate>`"
3. try to connect using remote-viewer
Actual results:
Connection fails, with the following error message:
(/usr/bin/remote-viewer:2416): Spice-Warning **:
ssl_verify.c:429:openssl_verify: Error in certificate chain verification: unable
to get local issuer certificate (num=20:depth1:/CN=XXX CA)
(remote-viewer:2416): GSpice-WARNING **: main-1:0: SSL_connect:
error:00000001:lib(0):func(0):reason(1)
Expected results:
remote-viewer / spice-gtk should accept the provided CA certificate as trusted, even if it is not a root certificate. The connection should not fail ;)
Additional info:
See https://lists.freedesktop.org/archives/spice-devel/2016-February/026214.html for a more in-depth description.https://gitlab.freedesktop.org/spice/spice/-/issues/22Spice Console won't show anything if newer Linux Hosts are in Screensaver2018-07-25T13:09:51ZHendrikSpice Console won't show anything if newer Linux Hosts are in ScreensaverHello all,
I am not sure if this is the right place to post this, please point me to the correct place if this isn't.
I am referring to an Issue that I opened with the ovirt Mailing List (https://lists.ovirt.org/archives/list/users@ovi...Hello all,
I am not sure if this is the right place to post this, please point me to the correct place if this isn't.
I am referring to an Issue that I opened with the ovirt Mailing List (https://lists.ovirt.org/archives/list/users@ovirt.org/thread/ZQS676FGIRSLSXKSMIUEJAKY4RAVVA6F/)
There is an Issue when you try to connect to a CentOS 7.5 Host that is currently in Powersaving / Screensaver Mode (default after 10 Minutes), the Spice Console will state that it is connected but there is no output and no keystrokes are accepted. If you now disable the Screensaver on the CentOS 7.5 Host the Console will instantly work correctly. The Issue appears to happen on MacOS, Fedora and Windows according to the Mailing List. I have tried both these Remote viewers:
https://github.com/jeffreywildman/homebrew-virt-manager
https://www.spice-space.org/osx-client.html
This is the Debug Output from the homebrew-virt-manager:
`
$ remote-viewer Downloads/console.vv --debug
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:17.609: Opening display to Downloads/console.vv
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:17.610: Guest (null) has a spice display
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:17.636: After open connection callback fd=-1
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:17.636: Opening connection to display at Downloads/console.vv
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:17.638: fullscreen display 0: 0
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:17.638: app is not in full screen
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:17.640: New spice channel 0x7fbf0e892390 SpiceMainChannel 0
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:17.640: notebook show status 0x7fbf10062320
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:18.615: main channel: opened
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:18.615: notebook show status 0x7fbf10062320
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:18.626: virt_viewer_app_set_uuid_string: UUID changed to 4ce91fb0-80da-4c20-a2f4-4e275b573ceb
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:18.626: app is not in full screen
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:18.715: app is not in full screen
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:18.733: New spice channel 0x7fbf1011a260 SpiceDisplayChannel 0
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:18.733: New spice channel 0x7fbf101802b0 SpiceCursorChannel 0
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:18.733: New spice channel 0x7fbf101804c0 SpiceInputsChannel 0
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:18.733: new inputs channel
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:18.809: creating spice display (#:0)
(remote-viewer:71083): virt-viewer-DEBUG: 16:12:18.809: Insert display 0 0x7fbf1008c330
`
I have also attached a Screenshot from the RemoteViewer Window of a VM that is working perfectly fine but is in Screensaver with the Output above: ![RemoteViewer](/uploads/813d28b456c08db23718dc81855c18b8/RemoteViewer.png)
Any help is greatly appreciated.
Thanks,
Hendrikhttps://gitlab.freedesktop.org/spice/win32/vd_agent/-/issues/4SPICE connection to VM no longer seamless with 12th login2018-06-03T10:19:23ZChristophe FergeauSPICE connection to VM no longer seamless with 12th login## Submitted by Christophe Fergau Fergau `@teuf`
Assigned to **Spice Bug List**
**[Link to original bug (#90819)](https://bugs.freedesktop.org/show_bug.cgi?id=90819)**
## Description
Moving here the content of https://bugzilla.red...## Submitted by Christophe Fergau Fergau `@teuf`
Assigned to **Spice Bug List**
**[Link to original bug (#90819)](https://bugs.freedesktop.org/show_bug.cgi?id=90819)**
## Description
Moving here the content of https://bugzilla.redhat.com/show_bug.cgi?id=1104697
Markus Stockhausen 2014-06-04 10:04:06 EDT
Description of problem:
After Live migration of a Windows VM several times between two hypervisor nodes SPICE and RDP connection suddenly stops working.
Version-Release number of selected component (if applicable):
Ovirt 3.4.1
Hypervisor nodes: Fedora 20
QEMU: 1.6.2
SPICE: 0.12.5
VM: Windows XP
VM drivers: guest tools 0.74
How reproducible:
100%
Steps to Reproduce:
1. Create a spice based windows VM
2. Install XP into that VM
3. Migrate VM several times between two hypervisor hosts
Actual results:
4. After 10-20 migrations the VM console cannot be opened any more. Neither through RDP nor through SPICE
Expected results:
Connection should work.
Additional info:
SPICE log (level 4) attaced
screenshot of spice connection try attached
[reply] [−]
Private
Comment 1 Markus Stockhausen 2014-06-04 10:07:36 EDT
Created attachment 902192 [details]
qemu/spice log
[reply] [−]
Private
Comment 2 Markus Stockhausen 2014-06-04 10:08:23 EDT
Created attachment 902193 [details]
spice console
[reply] [−]
Private
Comment 3 Markus Stockhausen 2014-06-04 10:24:53 EDT
As not clearly explained: I have spice-server 0.12.5 installed from the Fedora testing repositories. In 0.12.4 we had several endless loops because 64 bit time stamps were truncated to 32 bit.
[reply] [−]
Private
Comment 4 Markus Stockhausen 2014-06-04 10:46:26 EDT
A working VM shows the following SPICE log lines around the error:
((null):19914): SpiceWorker-Info **: red_worker.c:9635:display_channel_client_wait_for_init: creating encoder with id == 0
`<----- Here the connection hangs ---->`
`<----- Below the lines of a noraml working VM ---->`
((null):19914): Spice-Info **: reds.c:2014:reds_handle_auth_mechanism: Auth method: 1
((null):19914): Spice-Info **: reds.c:1421:reds_info_new_channel: channel 3:0, connected successfully, over Secure link
inputs_connect: inputs channel client create
[reply] [−]
Private
Comment 5 Markus Stockhausen 2014-06-04 15:30:01 EDT
Compiled spice-server 0.12.5 from scratch and added further logging instructions:
Ouput:
((null):10731): SpiceWorker-Info **: red_worker.c:9635:display_channel_client_wait_for_init: MST creating encoder with id == 0
((null):10731): SpiceWorker-Info **: red_worker.c:9637:display_channel_client_wait_for_init: MST glz_encoder_created
((null):10731): SpiceWorker-Info **: red_worker.c:9668:on_new_display_channel_client: MST red_channel_client_ack_zero_messages_window
((null):10731): SpiceWorker-Info **: red_worker.c:9678:on_new_display_channel_client: MST end
((null):10731): SpiceWorker-Info **: red_worker.c:10652:handle_new_display_channel: MST end
((null):10731): SpiceWorker-Info **: red_worker.c:11449:handle_dev_display_connect: MST connected
((null):10731): SpiceWorker-Info **: red_worker.c:10119:display_channel_handle_message: MST before_handle_message
((null):10731): Spice-Info **: red_channel.c:1531:red_channel_client_handle_message: MST start type=1
<---- The last tracepoint that is called in error case
The next tracepoint that is called in ok case --->
((null):10731): Spice-Info **: reds.c:2266:reds_accept_ssl_connection: MST start
((null):10731): Spice-Info **: reds.c:2230:reds_init_client_ssl_connection: MST start
Conclusion: The spice connection to the bad VM dos not jump into function reds_accept_ssl_connection() after the display_channel_client_wait_for_init() call.
I'm willing to enhance the tracepoints further. Any ideas where to search next. I'm having some problems to understand the watcher concept and to find a good point to debug the sent/received packets.
Oved Ourfali 2014-06-05 01:06:52 EDT
Whiteboard: virt
[reply] [−]
Private
Comment 6 Omer Frenkel 2014-06-05 03:06:45 EDT
please attach vdsm.log as well
Flags: needinfo?(mst@collogia.de)
[reply] [−]
Private
Comment 7 Markus Stockhausen 2014-06-05 03:28:24 EDT
Created attachment 902418 [details]
vdsm
Flags: needinfo?(mst@collogia.de)
[reply] [−]
Private
Comment 8 Markus Stockhausen 2014-06-05 03:30:19 EDT
VDSM log from migration target host attached. The log starts before the migration is initiated and ends after I tried to logon to SPICE console via webadmin.
[reply] [−]
Private
Comment 9 Markus Stockhausen 2014-06-05 04:42:14 EDT
Remark: The following behaviour can be reproduced even without doing a SPICE console connection. Just an online migration of the VM to the special spice debug enabled Fedora 20 hypervisor.
I narrowed the error down a bit in function red_worker_main(). In a normal working VM the endless loop in this function is permanently running. In the "damaged" VM this loop is suddenly halted. I placed two debugging messages before and after the call:
spice_info("before_poll");
num_events = poll(worker->poll_fds, MAX_EVENT_SOURCES, worker->event_timeout);
spice_info("after_poll");
On the bad VM that call suddenly does not return any more data and stalls. the last log line shows "before_poll". In the good VM that call will always return and the log is written on and on.
[reply] [−]
Private
Comment 10 Markus Stockhausen 2014-06-05 10:10:13 EDT
Please ignore my last comments.
I made some further analysis and the outcome is as follows:
When doing live migrations in the above described setup the SPICE performance might deteriorate on the target host. This can lead to a stall of the console display. Several problems might occur:
1) SPICE console lags. If you draw windows over the WinXP desktop very fast the react slowly and are running "behind" the mouse pointer.
2) SPICE console is no longer responsive. You cannot select any item on the WinXP desktop. Nevertheless the console display can be opened from webadmin.
3) SPICE console stays blank with the text connecting ...
This has been verified with the updated 0.12.5 spice-server and the original FC20 spice-server 0.12.4
Videos of case 2 are attached.
[reply] [−]
Private
Comment 11 Markus Stockhausen 2014-06-05 10:10:49 EDT
Created attachment 902559 [details]
normal performance before migration
[reply] [−]
Private
Comment 12 Markus Stockhausen 2014-06-05 10:11:18 EDT
Created attachment 902561 [details]
bad performance after migration
Itamar Heim 2014-06-08 02:30:00 EDT
Target Release: --- → 3.5.0
[reply] [−]
Private
Comment 13 Christophe Fergeau 2014-06-10 09:46:43 EDT
(In reply to Markus Stockhausen from comment 5)
> Conclusion: The spice connection to the bad VM dos not jump into function
> reds_accept_ssl_connection() after the
> display_channel_client_wait_for_init() call.
>
> I'm willing to enhance the tracepoints further. Any ideas where to search
> next. I'm having some problems to understand the watcher concept and to find
> a good point to debug the sent/received packets.
Have you tried getting a gdb backtrace when the server is hanging? ('debuginfo-install qemu-kvm' 'gdb --pid $qemu_pid' followed by 'thread apply all bt')
(In reply to Markus Stockhausen from comment 10)
> Please ignore my last comments.
All of them? There is no actual hang, but 'only' some very slow behaviour?
>
> This has been verified with the updated 0.12.5 spice-server and the original
> FC20 spice-server 0.12.4
>
Just to make sure I got you right, 0.12.4 was working ok (save for this 32 bit timer overflow), and this issue appeared in 0.12.5 ?
[reply] [−]
Private
Comment 14 Markus Stockhausen 2014-06-10 10:10:47 EDT
Some further tests showed that this problem occurs only in Windows XP VMs. To be precise we see the system performance degrading after each migration. So we can divide the error into several stages.
1) After 1-5 migration the SPICE display will get slower. The system seems to work normally. See video above.
2) Another 5-10 migrations later the system halts completely.
Exchanging SPICE 0.12.5 with 0.12.4 and vice versa does not change the situation
So to get closer to the error I will follow your advice and analyze what is going on, when the system stalls completely. Depending on that result I will open a new BZ or will continue this one.
[reply] [−]
Private
Comment 15 Markus Stockhausen 2014-06-10 10:28:19 EDT
Created attachment 907289 [details]
gdb output
[reply] [−]
Private
Comment 16 Markus Stockhausen 2014-06-10 10:30:26 EDT
GDB Output attached. The current version state in that situation is:
- qemu 1.6.2
- libspice-server 0.12.4
[reply] [−]
Private
Comment 17 Markus Stockhausen 2014-06-10 14:30:03 EDT
BZ1107835 has been created to analyze the major problem -> VM will stall after some migrations.
Markus Stockhausen 2014-06-10 14:30:33 EDT
Depends On: 1107835
Omer Frenkel 2014-06-11 01:53:52 EDT
Target Release: 3.5.0 → ---
Component: ovirt-engine-webadmin → spice
Version: 3.4 → 20
Assignee: bugs@ovirt.org → cfergeau@redhat.com
Product: oVirt → Fedora
QA Contact: pstehlik@redhat.com → extras-qa@fedoraproject.org
Markus Stockhausen 2014-06-13 15:11:16 EDT
Summary: Spice & RDP connection broken after live migration → SPICE connection to VM no longer seamless with 12th login
[reply] [−]
Private
Comment 18 Markus Stockhausen 2014-06-13 15:22:36 EDT
During long tests we isolated several bugs we encountered in the Ovirt environment. Therefore I changed this bug topic to better reflect a really reproducible testcase. Hope this is ok for the assignees.
Currently it boils down to a very simple and unwanted behaviour.
Server side:
Ovirt 3.4.2
Fedora 20 hyper visor nodes
qemu 1.6.2
libspice-server 0.12.4
Client side:
Windows 7
virt-viewer 0.6.0
Steps to reproduce:
1) Start a Windows XP SPICE VM from Ovirt webadmin
2) Connect to the console of the VM
3) virt-viewer will start and open the console window
4) Admin can control the VM "seamless" That means the mouse is not trapped in the conolse window. Simply dragging the mouse over the console window you can interact with the VM.
5) Logout from console by closing virt-viwer
6) Repeat steps 2-5 exactly 11 times
7) Logon to the VM for the 12th time.
Result:
When admin wants to interact with the console the mouse gets trapped in the console window. Admin must press SHIFT+F12 to get out of the window.
Expected result:
Seamless integration. No trapped mouse.
Markus Stockhausen 2014-06-13 15:45:53 EDT
No longer depends On: 1107835
[reply] [−]
Private
Comment 19 Marc-Andre Lureau 2014-06-13 17:21:33 EDT
When the mouse is trapped, can you verify if the vdagent is still running? most likely, not, could you get the vdagent & vdservice logs when the bug occurs? thanks
Flags: needinfo?(mst@collogia.de)
[reply] [−]
Private
Comment 20 Markus Stockhausen 2014-06-14 10:35:52 EDT
Created attachment 908784 [details]
vdservice
Flags: needinfo?(mst@collogia.de)
[reply] [−]
Private
Comment 21 Markus Stockhausen 2014-06-14 10:36:22 EDT
Created attachment 908785 [details]
vdagent
[reply] [−]
Private
Comment 22 Markus Stockhausen 2014-06-14 10:37:36 EDT
Logs attached - please don't tell me vdagent/vdservice are stopped if a user logs into a server too often :(
[reply] [−]
Private
Comment 23 Markus Stockhausen 2014-06-14 10:49:16 EDT
...
if (!normal_restart && ++_agent_restarts > VD_AGENT_MAX_RESTARTS) {
vd_printf("Agent restarted too many times");
ret = false;
stop();
}
if (ret && kill_agent() && launch_agent()) {
if (time - _last_agent_restart_time > VD_AGENT_RESTART_COUNT_RESET_INTERVAL) {
_agent_restarts = 0;
}
...
That math looks too anticipatory. In that setup vdservice will kill the agent if a user logs into the console with an interval of < 60 seconds. Is there no better way to handle that?
[reply] [−]
Private
Comment 24 Markus Stockhausen 2014-06-14 10:55:01 EDT
Windows XP ist not so graceful with agent restarts as newer versions:
case WAIT_OBJECT_0 + VD_STATIC_EVENTS_COUNT:
vd_printf("Agent killed");
if (_system_version == SYS_VER_WIN_XP_CLASS) {
restart_agent(false);
} else if (_system_version == SYS_VER_WIN_7_CLASS) {
kill_agent();
// Assume agent was killed due to console disconnect, and wait for agent
// normal restart due to console connect. If the agent is not alive yet,
// it was killed manually (or crashed), so let's restart it.
if (WaitForSingleObject(_control_event, VD_AGENT_RESTART_INTERVAL) ==
WAIT_OBJECT_0) {
handle_control_event();
}
if (_running && !_agent_alive) {
restart_agent(false);
}
Any reason for that?
[reply] [−]
Private
Comment 25 Christophe Fergeau 2014-06-16 04:50:34 EDT
The bit of code you quote was added as part of https://bugzilla.redhat.com/show_bug.cgi?id=845222
Thanks for the very detailed investigation!
I'm not sure if we have a spice-vdagent-win upstream bugzilla component though :((
[reply] [−]
Private
Comment 26 Uri Lublin 2014-06-16 05:32:41 EDT
(In reply to Markus Stockhausen from comment 23)
The logic of this code is:
When spice-vdagent exits, spice-vdservice runs a new instance of spice-vdagent.
If something prevents the spice-vdagent from starting, for example a problem with the virtio-serial device/driver, spice-vdservice tries VD_AGENT_MAX_RESTARTS consecutive times and stops trying.
The code assumes that if there is no problem, at least one instance out of the VD_AGENT_MAX_RESTARTS vdagents will live for more than VD_AGENT_RESTART_COUNT_RESET_INTERVAL.
The problem is partially due to making the windows spice vdagent exit when the spice client disconnects.
[reply] [−]
Private
Comment 27 Markus Stockhausen 2014-06-26 06:08:25 EDT
(In reply to Christophe Fergeau from comment 25)
> The bit of code you quote was added as part of
> https://bugzilla.redhat.com/show_bug.cgi?id=845222
> Thanks for the very detailed investigation!
> I'm not sure if we have a spice-vdagent-win upstream bugzilla component
> though :((
Is there some better place to ask for a fix (outside RH bugzilla)?
Flags: needinfo?(cfergeau@redhat.com)
[reply] [−]
Private
Comment 28 Cole Robinson 2015-03-31 15:41:02 EDT
Markus, there is an upstream spice w32 agent bug tracker, but no guarantees a fix will be generated. at least the bug has a better chance of surviving since this one will be autoclosed when F20 is end-of-life
https://bugs.freedesktop.org/buglist.cgi?component=win32%20agent&product=Spicehttps://gitlab.freedesktop.org/spice/spice-gtk/-/issues/128spice-client-glib-2.0.vapi crash on install2021-08-20T07:21:44Zdavid arledgespice-client-glib-2.0.vapi crash on installhttps://gitlab.freedesktop.org/spice/spice-gtk/-/issues/102spice client crashes when running full-screen game (league of legends) with I...2020-11-26T02:33:11ZFelix Yanfelixonmars@archlinux.orgspice client crashes when running full-screen game (league of legends) with Intel GVT-gI am getting constant crashes with this combination: Fullscreen game (League of Legends) with Intel GVT-g. I have tried both gnome-boxes and virt-manager and they crash in the same way, so I suspect it may have something to do with spice...I am getting constant crashes with this combination: Fullscreen game (League of Legends) with Intel GVT-g. I have tried both gnome-boxes and virt-manager and they crash in the same way, so I suspect it may have something to do with spice-gtk.
The crashes are always after two libvirt errors:
> Jun 20 02:54:39 flygon.felixc.at libvirtd[5065]: End of file while reading data: Input/output error
> Jun 20 02:54:39 flygon.felixc.at libvirtd[5065]: End of file while reading data: Input/output error
And the tracebacks contain spice clients:
Jun 20 02:54:40 flygon.felixc.at systemd-coredump[32308]: Process 32236 (python3) of user 0 dumped core.
> Stack trace of thread 32236:
> #0 0x00007ffff7d7e755 raise (libc.so.6)
> #1 0x00007ffff7d69851 abort (libc.so.6)
> #2 0x00007ffff7d69727 __assert_fail_base.cold (libc.so.6)
> #3 0x00007ffff7d77026 __assert_fail (libc.so.6)
> #4 0x00007ffff5967a11 n/a (libX11.so.6)
> #5 0x00007ffff5967ac1 n/a (libX11.so.6)
> #6 0x00007ffff5967dbd _XEventsQueued (libX11.so.6)
> #7 0x00007ffff5959978 XPending (libX11.so.6)
> #8 0x00007fffeef14773 n/a (libgdk-3.so.0)
> #9 0x00007ffff63b2e72 g_main_context_check (libglib-2.0.so.0)
> #10 0x00007ffff63b4766 n/a (libglib-2.0.so.0)
> #11 0x00007ffff63b48ae g_main_context_iteration (libglib-2.0.so.0)
> #12 0x00007ffff616869e g_application_run (libgio-2.0.so.0)
> #13 0x00007ffff7f426d0 ffi_call_unix64 (libffi.so.6)
> #14 0x00007ffff7f420a0 ffi_call (libffi.so.6)
> #15 0x00007ffff652b664 n/a (_gi.cpython-37m-x86_64-linux-gnu.so)
> #16 0x00007ffff652ac4c n/a (_gi.cpython-37m-x86_64-linux-gnu.so)
> #17 0x00007ffff7adb49b PyObject_Call (libpython3.7m.so.1.0)
> #18 0x00007ffff7b8e83e _PyEval_EvalFrameDefault (libpython3.7m.so.1.0)
> #19 0x00007ffff7ad9d09 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0)
> #20 0x00007ffff7b20882 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0)
> #21 0x00007ffff7b8d032 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0)
> #22 0x00007ffff7b206db _PyFunction_FastCallKeywords (libpython3.7m.so.1.0)
> #23 0x00007ffff7b8d032 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0)
> #24 0x00007ffff7ad9d09 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0)
> #25 0x00007ffff7b20882 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0)
> #26 0x00007ffff7b8d22d _PyEval_EvalFrameDefault (libpython3.7m.so.1.0)
> #27 0x00007ffff7ad9d09 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0)
> #28 0x00007ffff7adac64 PyEval_EvalCodeEx (libpython3.7m.so.1.0)
> #29 0x00007ffff7adac8c PyEval_EvalCode (libpython3.7m.so.1.0)
> #30 0x00007ffff7c03694 n/a (libpython3.7m.so.1.0)
> #31 0x00007ffff7c04b6e PyRun_FileExFlags (libpython3.7m.so.1.0)
> #32 0x00007ffff7c08035 PyRun_SimpleFileExFlags (libpython3.7m.so.1.0)
> #33 0x00007ffff7c0a2a7 n/a (libpython3.7m.so.1.0)
> #34 0x00007ffff7c0a4ec _Py_UnixMain (libpython3.7m.so.1.0)
> #35 0x00007ffff7d6aee3 __libc_start_main (libc.so.6)
> #36 0x000055555555505e _start (python3.7)
>
> Stack trace of thread 32281:
> #0 0x00007ffff7e3ac6d syscall (libc.so.6)
> #1 0x00007ffff636238d n/a (libglib-2.0.so.0)
> #2 0x00007fffc31357d0 n/a (libspice-client-glib-2.0.so.8)
> #3 0x00007fffc3100a0a n/a (libspice-client-glib-2.0.so.8)
> #4 0x00007fffc30fab10 n/a (libspice-client-glib-2.0.so.8)
> #5 0x00007fffc30fcafd n/a (libspice-client-glib-2.0.so.8)
> #6 0x00007fffc3135591 n/a (libspice-client-glib-2.0.so.8)
> #7 0x00007ffff638ff21 n/a (libglib-2.0.so.0)
> #8 0x00007ffff7f1057f start_thread (libpthread.so.0)
> #9 0x00007ffff7e3ff13 __clone (libc.so.6)
>
> Stack trace of thread 32252:
> #0 0x00007ffff7e35497 __poll (libc.so.6)
> #1 0x00007ffff63b47c0 n/a (libglib-2.0.so.0)
> #2 0x00007ffff63b48ae g_main_context_iteration (libglib-2.0.so.0)
> #3 0x00007ffff63b4902 n/a (libglib-2.0.so.0)
> #4 0x00007ffff638ff21 n/a (libglib-2.0.so.0)
> #5 0x00007ffff7f1057f start_thread (libpthread.so.0)
> #6 0x00007ffff7e3ff13 __clone (libc.so.6)
>
> Stack trace of thread 32253:
> #0 0x00007ffff7e35497 __poll (libc.so.6)
> #1 0x00007ffff63b47c0 n/a (libglib-2.0.so.0)
> #2 0x00007ffff63b48ae g_main_context_iteration (libglib-2.0.so.0)
> #3 0x00007fffef486bde n/a (libdconfsettings.so)
> #4 0x00007ffff638ff21 n/a (libglib-2.0.so.0)
> #5 0x00007ffff7f1057f start_thread (libpthread.so.0)
> #6 0x00007ffff7e3ff13 __clone (libc.so.6)
>
> Stack trace of thread 32280:
> #0 0x00007ffff7e3ac6d syscall (libc.so.6)
> #1 0x00007ffff6362461 g_cond_wait (libglib-2.0.so.0)
> #2 0x00007fffc31357d0 n/a (libspice-client-glib-2.0.so.8)
> #3 0x00007fffc3100a0a n/a (libspice-client-glib-2.0.so.8)
> #4 0x00007fffc30fab10 n/a (libspice-client-glib-2.0.so.8)
> #5 0x00007fffc30fcafd n/a (libspice-client-glib-2.0.so.8)
> #6 0x00007fffc3135591 n/a (libspice-client-glib-2.0.so.8)
> #7 0x00007ffff638ff21 n/a (libglib-2.0.so.0)
> #8 0x00007ffff7f1057f start_thread (libpthread.so.0)
> #9 0x00007ffff7e3ff13 __clone (libc.so.6)
>
> Stack trace of thread 32271:
> #0 0x00007ffff7e35497 __poll (libc.so.6)
> #1 0x00007fffc27cec90 n/a (libusb-1.0.so.0)
> #2 0x00007ffff7f1057f start_thread (libpthread.so.0)
> #3 0x00007ffff7e3ff13 __clone (libc.so.6)
>
> Stack trace of thread 32283:
> #0 0x00007ffff7e3ac6d syscall (libc.so.6)
> #1 0x00007ffff6362461 g_cond_wait (libglib-2.0.so.0)
> #2 0x00007fffc31357d0 n/a (libspice-client-glib-2.0.so.8)
> #3 0x00007fffc3100a0a n/a (libspice-client-glib-2.0.so.8)
> #4 0x00007fffc30fab10 n/a (libspice-client-glib-2.0.so.8)
> #5 0x00007fffc30fcafd n/a (libspice-client-glib-2.0.so.8)
> #6 0x00007fffc3135591 n/a (libspice-client-glib-2.0.so.8)
> #7 0x00007ffff638ff21 n/a (libglib-2.0.so.0)
> #8 0x00007ffff7f1057f start_thread (libpthread.so.0)
> #9 0x00007ffff7e3ff13 __clone (libc.so.6)
>
> Stack trace of thread 32285:
> #0 0x00007ffff7e3ac6d syscall (libc.so.6)
> #1 0x00007ffff6362461 g_cond_wait (libglib-2.0.so.0)
> #2 0x00007fffc31357d0 n/a (libspice-client-glib-2.0.so.8)
> #3 0x00007fffc3100a0a n/a (libspice-client-glib-2.0.so.8)
> #4 0x00007fffc30fab10 n/a (libspice-client-glib-2.0.so.8)
> #5 0x00007fffc30fcafd n/a (libspice-client-glib-2.0.so.8)
> #6 0x00007fffc3135591 n/a (libspice-client-glib-2.0.so.8)
> #7 0x00007ffff638ff21 n/a (libglib-2.0.so.0)
> #8 0x00007ffff7f1057f start_thread (libpthread.so.0)
> #9 0x00007ffff7e3ff13 __clone (libc.so.6)
>
> Stack trace of thread 32282:
> #0 0x00007ffff7e3ac6d syscall (libc.so.6)
> #1 0x00007ffff6362461 g_cond_wait (libglib-2.0.so.0)
> #2 0x00007fffc31357d0 n/a (libspice-client-glib-2.0.so.8)
> #3 0x00007fffc3100a0a n/a (libspice-client-glib-2.0.so.8)
> #4 0x00007fffc30fab10 n/a (libspice-client-glib-2.0.so.8)
> #5 0x00007fffc30fcafd n/a (libspice-client-glib-2.0.so.8)
> #6 0x00007fffc3135591 n/a (libspice-client-glib-2.0.so.8)
> #7 0x00007ffff638ff21 n/a (libglib-2.0.so.0)
> #8 0x00007ffff7f1057f start_thread (libpthread.so.0)
> #9 0x00007ffff7e3ff13 __clone (libc.so.6)
>
> Stack trace of thread 32279:
> #0 0x00007ffff7e3ac6d syscall (libc.so.6)
> #1 0x00007ffff636238d n/a (libglib-2.0.so.0)
> #2 0x00007fffc31357d0 n/a (libspice-client-glib-2.0.so.8)
> #3 0x00007fffc3100a0a n/a (libspice-client-glib-2.0.so.8)
> #4 0x00007fffc30fab10 n/a (libspice-client-glib-2.0.so.8)
> #5 0x00007fffc30fcafd n/a (libspice-client-glib-2.0.so.8)
> #6 0x00007fffc3135591 n/a (libspice-client-glib-2.0.so.8)
> #7 0x00007ffff638ff21 n/a (libglib-2.0.so.0)
> #8 0x00007ffff7f1057f start_thread (libpthread.so.0)
> #9 0x00007ffff7e3ff13 __clone (libc.so.6)
>
> Stack trace of thread 32284:
> #0 0x00007ffff7e3ac6d syscall (libc.so.6)
> #1 0x00007ffff6362461 g_cond_wait (libglib-2.0.so.0)
> #2 0x00007fffc31357d0 n/a (libspice-client-glib-2.0.so.8)
> #3 0x00007fffc3100a0a n/a (libspice-client-glib-2.0.so.8)
> #4 0x00007fffc30fab10 n/a (libspice-client-glib-2.0.so.8)
> #5 0x00007fffc30fcafd n/a (libspice-client-glib-2.0.so.8)
> #6 0x00007fffc3135591 n/a (libspice-client-glib-2.0.so.8)
> #7 0x00007ffff638ff21 n/a (libglib-2.0.so.0)
> #8 0x00007ffff7f1057f start_thread (libpthread.so.0)
> #9 0x00007ffff7e3ff13 __clone (libc.so.6)
>
> Stack trace of thread 32286:
> #0 0x00007ffff7f163c5 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
> #1 0x00007fffb0d77f5c n/a (i965_dri.so)
> #2 0x00007fffb0d77b58 n/a (i965_dri.so)
> #3 0x00007ffff7f1057f start_thread (libpthread.so.0)
> #4 0x00007ffff7e3ff13 __clone (libc.so.6)
>
> Stack trace of thread 32261:
> #0 0x00007ffff7f18cc6 do_futex_wait.constprop.0 (libpthread.so.0)
> #1 0x00007ffff7f18dc8 __new_sem_wait_slow.constprop.0 (libpthread.so.0)
> #2 0x00007ffff7acaf39 PyThread_acquire_lock_timed (libpython3.7m.so.1.0)
> #3 0x00007ffff7b7eb0f n/a (libpython3.7m.so.1.0)
> #4 0x00007ffff7b20fa4 _PyMethodDef_RawFastCallKeywords (libpython3.7m.so.1.0)
> #5 0x00007ffff7b4d0ef _PyMethodDescr_FastCallKeywords (libpython3.7m.so.1.0)
> #6 0x00007ffff7b918b3 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0)
> #7 0x00007ffff7ad9d09 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0)
> #8 0x00007ffff7b20882 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0)
> #9 0x00007ffff7b8d032 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0)
> #10 0x00007ffff7ad9d09 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0)
> #11 0x00007ffff7b20882 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0)
> #12 0x00007ffff7b8d032 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0)
> #13 0x00007ffff7adadbb _PyFunction_FastCallDict (libpython3.7m.so.1.0)
> #14 0x00007ffff7aea818 _PyObject_Call_Prepend (libpython3.7m.so.1.0)
> #15 0x00007ffff7adb49b PyObject_Call (libpython3.7m.so.1.0)
> #16 0x00007ffff7b8e83e _PyEval_EvalFrameDefault (libpython3.7m.so.1.0)
> #17 0x00007ffff7b206db _PyFunction_FastCallKeywords (libpython3.7m.so.1.0)
> #18 0x00007ffff7b8d032 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0)
> #19 0x00007ffff7b206db _PyFunction_FastCallKeywords (libpython3.7m.so.1.0)
> #20 0x00007ffff7b8d032 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0)
> #21 0x00007ffff7adadbb _PyFunction_FastCallDict (libpython3.7m.so.1.0)
> #22 0x00007ffff7aea818 _PyObject_Call_Prepend (libpython3.7m.so.1.0)
> #23 0x00007ffff7adb49b PyObject_Call (libpython3.7m.so.1.0)
> #24 0x00007ffff7c09e97 n/a (libpython3.7m.so.1.0)
> #25 0x00007ffff7bb1fa5 n/a (libpython3.7m.so.1.0)
> #26 0x00007ffff7f1057f start_thread (libpthread.so.0)
> #27 0x00007ffff7e3ff13 __clone (libc.so.6)
>
> Stack trace of thread 32273:
> #0 0x00007ffff7e3ac6d syscall (libc.so.6)
> #1 0x00007ffff6362461 g_cond_wait (libglib-2.0.so.0)
> #2 0x00007fffc31357d0 n/a (libspice-client-glib-2.0.so.8)
> #3 0x00007fffc3100a0a n/a (libspice-client-glib-2.0.so.8)
> #4 0x00007fffc30fab10 n/a (libspice-client-glib-2.0.so.8)
> #5 0x00007fffc30fcafd n/a (libspice-client-glib-2.0.so.8)
> #6 0x00007fffc3135591 n/a (libspice-client-glib-2.0.so.8)
> #7 0x00007ffff638ff21 n/a (libglib-2.0.so.0)
> #8 0x00007ffff7f1057f start_thread (libpthread.so.0)
> #9 0x00007ffff7e3ff13 __clone (libc.so.6)
>
> Stack trace of thread 32272:
> #0 0x00007ffff7e35497 __poll (libc.so.6)
> #1 0x00007fffc27c8419 n/a (libusb-1.0.so.0)
> #2 0x00007fffc27c9440 libusb_handle_events_timeout_completed (libusb-1.0.so.0)
> #3 0x00007fffc27c9530 libusb_handle_events (libusb-1.0.so.0)
> #4 0x00007fffc311fe8a n/a (libspice-client-glib-2.0.so.8)
> #5 0x00007ffff638ff21 n/a (libglib-2.0.so.0)
> #6 0x00007ffff7f1057f start_thread (libpthread.so.0)
> #7 0x00007ffff7e3ff13 __clone (libc.so.6)
Sorry if this is the wrong place to report, and please kindly let me know where should I report this. Thanks!https://gitlab.freedesktop.org/spice/win32/vd_agent/-/issues/21Spice agent behavior degraded under Windows 112022-10-15T19:15:06ZbrainchildSpice agent behavior degraded under Windows 11
# Description
On a Windows 11 guest, the services normally provided by the Spice agent are inconsistently available from the Spice client (which is operated locally on the host in the current configuration), with sensitivity to spec...
# Description
On a Windows 11 guest, the services normally provided by the Spice agent are inconsistently available from the Spice client (which is operated locally on the host in the current configuration), with sensitivity to specific configuration that should not affect agent function.
# Details
Regrettably, there is no specific test case that may be reproduced. Windows 11 was provisioned as a guest operating system targeted for interaction through a Spice client. The installation has no known problems besides the current one.
Early observations included the following:
1. Clipboard sharing is one directional, with functionality for content from the client to the guest, but guest *copy* commands not being propagated to the client environment.
2. Client cursor is not provided. The cursor is rendered by the guest.
3. Changes in display resolution by guest in response to resizing of client Window normally occurred, but occasionally the guest reverts to a standard display resolution.
[Log files](/uploads/94a0e8aa17f8d204e5c223a02acc2742/vdlogs.zip) show alarming findings.
Furthermore, [earlier discussion](https://gitlab.freedesktop.org/spice/win32/spice-nsis/-/issues/16#note_1578374) has revealed that, against expectation, the agent had no handles to system resources during operation.
Generally, various agent functions are intermittent and sensitive to changes that should be unrelated.
# Environment
- Operating system: Linux Mint 21
- Architecture: x68 64-bit
- kernel version: 6.0.0
- libvirt version: 8.0.0
- Hypervisor and version: Qemu 6.2.0 (used with KVM)https://gitlab.freedesktop.org/spice/spice-gtk/-/issues/57sometimes cannot cancel or close the file transfer dialog when agent disconnect2018-06-10T23:31:56ZBugzilla Migration Usersometimes cannot cancel or close the file transfer dialog when agent disconnect## Submitted by xia..@..at.com
Assigned to **Spice Bug List**
**[Link to original bug (#99984)](https://bugs.freedesktop.org/show_bug.cgi?id=99984)**
## Description
Created attachment 129949
file transfter dialog
summary:
sometim...## Submitted by xia..@..at.com
Assigned to **Spice Bug List**
**[Link to original bug (#99984)](https://bugs.freedesktop.org/show_bug.cgi?id=99984)**
## Description
Created attachment 129949
file transfter dialog
summary:
sometimes cannot cancel or close the file transfer dialog when agent disconnect
version:
virt-viewer-6.0-2017021715110.spice.nightly.fc25.x86_64
steps:
1. Prepare a vm which has not enough disk space for a iso file transfer.
2. transfer the iso file to the vm.
3. during the iso file transferring, select and drag the other 5 (the more the better) files into the vm.
4. redo step 3 several times to increase the file transferring counts.
Result:
the agent will fail during transferring and the transferring dialog can't be closed/cancelled.
**Attachment 129949**, "file transfter dialog":
![file_transfer_dialog](/uploads/43caae8634e228b64371855dcc9f7b62/file_transfer_dialog.png)https://gitlab.freedesktop.org/spice/spice/-/issues/17Smartcards with multiple slots now seen in the VM2019-10-31T12:53:11ZBugzilla Migration UserSmartcards with multiple slots now seen in the VM## Submitted by Laurent Bigonville
Assigned to **Spice Bug List**
**[Link to original bug (#105693)](https://bugs.freedesktop.org/show_bug.cgi?id=105693)**
## Description
Hi,
I've a cardos smartcard with multiple slots.
When I'm...## Submitted by Laurent Bigonville
Assigned to **Spice Bug List**
**[Link to original bug (#105693)](https://bugs.freedesktop.org/show_bug.cgi?id=105693)**
## Description
Hi,
I've a cardos smartcard with multiple slots.
When I'm adding the opensc-pkcs11.so module on the host, the card doesn't appear in the VM. If I'm changing that to the onepin-opensc-pkcs11.so the card is seen by pcscd.
I guess this is happening because there are multiples slots. Shouldn't all the slots be exposed in the VM as well in that case?
libcacard: 2.5.3
qemu: 2.11
spice: 0.14.0
spice-gtk: 0.34https://gitlab.freedesktop.org/spice/spice-gtk/-/issues/16smartcard passthrough can't handle multiple sessions in the same process2018-06-05T16:30:22ZChristophe Fergeausmartcard passthrough can't handle multiple sessions in the same process## Submitted by Christophe Fergau Fergau `@teuf`
Assigned to **Spice Bug List**
**[Link to original bug (#41536)](https://bugs.freedesktop.org/show_bug.cgi?id=41536)**
## Description
```
11:55 `< hansg>` teuf, I'm currently re-doi...## Submitted by Christophe Fergau Fergau `@teuf`
Assigned to **Spice Bug List**
**[Link to original bug (#41536)](https://bugs.freedesktop.org/show_bug.cgi?id=41536)**
## Description
```
11:55 `< hansg>` teuf, I'm currently re-doing some of the usb-device-manager
stuff. One of the things I got wrong is that I didn't keep in
mind that one process can have multiple sessions open (think
vinagre with 2 spice tabs)
11:57 `< hansg>` teuf, it seems you've made the same mistake with the
smartcard stuff.
11:58 `< hansg>` Hmm, never mind, it seems all transfer to / from the reader
happen by: vreader_xfr_bytes, so as long as the 2 sessions
are handled by the same thread, all should be will I think
12:00 `< hansg>` One problem could be the use of vreader_set_id, actually
looking at the code, this will trigger for a second session:
g_return_if_fail(vreader_get_id(reader) == -1);
12:01 `< hansg>` I guess the mapping of ids -> readers should be moved to
channel-smartcard.c instead of relying on the mapping inside
libcacard (assuming that the id is only used for mapping and
not for other uses inside libcacard)
12:03 -!- yonit [~yhalperi@nat-pool-tlv-t1.redhat.com] has quit [Leaving]
12:04 `< teuf>` hansg: I definitely haven't thought at all about multiple
widget instances in the same process while doing the smartcard
stuff
12:05 `< hansg>` teuf, yeah I know that feeling :)
12:05 `< teuf>` :)
12:05 `< hansg>` Note multiple widgets (aka SpiceDisplay) != multiple sessions
12:05 `< hansg>` One session can have multiple widgets (think multi monitor)
12:05 `< teuf>` ah yup
12:06 -!- yonit [~yhalperi@nat-pool-tlv-t1.redhat.com] has joined #spice
12:07 `< hansg>` Luckily for the smartcard stuff the widget does not seem to
do to much, actually the only thing it does is do a
spice_channel_connect() on the smartcard channel. So with a
multi mon setup this will happen multiple times, but
spice-channel.c protects against this
12:12 -!- alon [~alon@85.64.131.212.dynamic.barak-online.net] has quit [Read
error: 145 (Connection timed out)]
12:13 `< hansg>` Hmm, channel-smartcard.c will try to send messages on
smartcard reader detection even if the channel is not
connected (think an app using spice-client-glib but not
spice-client-gtk)
```https://gitlab.freedesktop.org/spice/win32/qxl-wddm-dod/-/issues/5Slow mouse movement when using spice agent under Windows 8 and Windows Server...2018-11-28T22:03:51ZBugzilla Migration UserSlow mouse movement when using spice agent under Windows 8 and Windows Server 2012 R2 guests## Submitted by Thiago Basilio
Assigned to **Victor Toso**
**[Link to original bug (#91219)](https://bugs.freedesktop.org/show_bug.cgi?id=91219)**
## Description
I'm experiencing problems with spice-vdagent under Windows 8 and Win...## Submitted by Thiago Basilio
Assigned to **Victor Toso**
**[Link to original bug (#91219)](https://bugs.freedesktop.org/show_bug.cgi?id=91219)**
## Description
I'm experiencing problems with spice-vdagent under Windows 8 and Windows Server 2012 R2 guests.
The guests are using VirtIO version 0.1.105. The spice-vdagent is version 0.7.3.
When spice-vdagent is running, mouse movement seems very sluggish. Very similar to a 1993-era serial mouse. If I stop the spice-vdagent service, mouse movement gets smooth again.
This situation also happens if:
... 1) The 'USB Tablet' device is added or removed;
... 2) The PS/2 mouse is added or removed;
... 3) The standard mouse (PS/2 mouse) is set-up as a 'USB Generic Mouse'.https://gitlab.freedesktop.org/spice/usbredir/-/issues/34SIGILL triggerred by usbredirparser_serialize with nullptr in usbredirparser....2023-12-18T06:00:08Z王 平SIGILL triggerred by usbredirparser_serialize with nullptr in usbredirparser.c:1766I have found SIGILL crashes with usbredir-0.13.0 when running some fuzzing tests.
[usbredir-0.13.0-SIGILL.tar.gz](/uploads/374e4980d1cb1657b38ed1c464493a5c/usbredir-0.13.0-SIGILL.tar.gz)
Repordocing Steps:
1. Trigger the SIGILL crash...I have found SIGILL crashes with usbredir-0.13.0 when running some fuzzing tests.
[usbredir-0.13.0-SIGILL.tar.gz](/uploads/374e4980d1cb1657b38ed1c464493a5c/usbredir-0.13.0-SIGILL.tar.gz)
Repordocing Steps:
1. Trigger the SIGILL crashes with PoC attached.
`./usbredirparserfuzz < out2/default/crashes/id\:000033\,sig\:04\,src\:000083\,time\:5394\,execs\:37324\,op\:havoc\,rep\:3`
[AFL++ 0cc14d0bc3c5] /data/openeuler/usbredir/fuzzing # date
Mon Dec 18 02:50:16 AM UTC 2023
[AFL++ 0cc14d0bc3c5] /data/openeuler/usbredir/fuzzing # ./usbredirparserfuzz < out2/default/crashes/id\:000033\,sig\:04\,src\:000083\,time\:5394\,execs\:37324\,op\:havoc\,rep\:3
Illegal instruction
2. Debug Information:
`gdb ./usbredirparserfuzz`
![usbredir-0.13.0](/uploads/a6a5905dab39106554abec487a3f29c9/usbredir-0.13.0.png)
```
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./usbredirparserfuzz...
(gdb) run < out2/default/crashes/id\:000033\,sig\:04\,src\:000083\,time\:5394\,execs\:37324\,op\:havoc\,rep\:3
Starting program: /data/openeuler/usbredir/fuzzing/usbredirparserfuzz < out2/default/crashes/id\:000033\,sig\:04\,src\:000083\,time\:5394\,execs\:37324\,op\:havoc\,rep\:3
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGILL, Illegal instruction.
0x000055555568cd92 in serialize_data (parser=<optimized out>, state=<optimized out>, pos=0x7fffffffdc00, remain=0x7fffffffdc20, data=0x0, len=<optimized out>, desc=0x55555558cd00 <str.20> "packet-data") at ../usbredirparser/usbredirparser.c:1661
1661 memcpy(*pos, data, len);
(gdb) p data
$1 = (uint8_t *) 0x0
(gdb) p len
$2 = <optimized out>
(gdb) bt
#0 0x000055555568cd92 in serialize_data (parser=<optimized out>, state=<optimized out>, pos=0x7fffffffdc00, remain=0x7fffffffdc20,
data=0x0, len=<optimized out>, desc=0x55555558cd00 <str.20> "packet-data") at ../usbredirparser/usbredirparser.c:1661
#1 0x000055555568b237 in usbredirparser_serialize (parser_pub=<optimized out>, state_dest=<optimized out>, state_len=<optimized out>)
at ../usbredirparser/usbredirparser.c:1766
#2 0x000055555567735b in (anonymous namespace)::try_serialize (parser=0x631000014824) at usbredirparserfuzz.cc:330
#3 LLVMFuzzerTestOneInput (data=<optimized out>, size=<optimized out>) at usbredirparserfuzz.cc:424
#4 0x000055555567e8d3 in main (argc=<optimized out>, argv=<optimized out>) at usbredirparserfuzz.cc:458
(gdb)
```
A more details debug info:
```
(gdb)bu usbredirparser.c:1661
Breakpoint 1 at 0x55555568c9ac: file ../usbredirparser/usbredirparser.c, line 1661.
(gdb) b usbredirparser.c:1766
Breakpoint 2 at 0x55555568b21a: file ../usbredirparser/usbredirparser.c, line 1766.
(gdb) usbredirparserfuzz.cc:330
Undefined command: "usbredirparserfuzz.cc". Try "help".
(gdb) b usbredirparserfuzz.cc:330
Breakpoint 3 at 0x55555567705f: usbredirparserfuzz.cc:330. (2 locations)
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /data/openeuler/usbredir/fuzzing/usbredirparserfuzz < out2/default/crashes/id\:000033\,sig\:04\,src\:000083\,time\:5394\,execs\:37324\,op\:havoc\,rep\:3
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 3, (anonymous namespace)::try_serialize (parser=0x617000000080) at usbredirparserfuzz.cc:330
330 ret = usbredirparser_serialize(parser, &state, &len);
(gdb) p state
$1 = (uint8_t *) 0x0
(gdb) p len
$2 = 0
(gdb) c
Continuing.
Breakpoint 2, usbredirparser_serialize (parser_pub=<optimized out>, state_dest=<optimized out>, state_len=<optimized out>) at ../usbredirparser/usbredirparser.c:1766
1766 if (serialize_data(parser, &state, &pos, &remain,
(gdb) p state
$3 = (uint8_t *) 0x631000014800 "1PRU"
(gdb) p len
$4 = <optimized out>
(gdb) c
Continuing.
Program received signal SIGILL, Illegal instruction.
0x000055555568cd92 in serialize_data (parser=<optimized out>, state=<optimized out>, pos=0x7fffffffdc00, remain=0x7fffffffdc20, data=0x0, len=<optimized out>, desc=0x55555558cd00 <str.20> "packet-data") at ../usbredirparser/usbredirparser.c:1661
1661 memcpy(*pos, data, len);
(gdb) p data
$5 = (uint8_t *) 0x0
(gdb) p len
$6 = <optimized out>
(gdb) p pos
$7 = (uint8_t **) 0x7fffffffdc00
```
The fuzzing code I use is also attached above!