| Summary: | SIGSEGV - spice-server - on file transfer while killing the agent | ||
|---|---|---|---|
| Product: | Spice | Reporter: | Victor Toso <bugzilla> |
| Component: | server | Assignee: | Spice Bug List <spice-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | bugzilla |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Victor Toso
2016-05-16 06:08:18 UTC
Interesting part of the log is Spice-INFO: reds.c:3214:spice_server_char_device_add_interface: CHAR_DEVICE vdagent (process:17063): Spice-DEBUG: char-device.c:694:red_char_device_reset_dev_instance: sin 0x5598a9458d58, char device 0x5598a945d150 (process:17063): Spice-DEBUG: char-device.c:810:red_char_device_start: char device 0x5598a945d150 main_channel_handle_parsed: agent start (...) __red_char_device_write_buffer_get: token violation: dev 0x5598a945d150 client 0x5598a949f780 red_char_device_handle_client_overflow: dev 0x5598a945d150 client 0x5598a944c3a0 spice is latest master, qemu is not (fedora 23) (In reply to Victor Toso from comment #2) > spice is latest master, qemu is not (fedora 23) As things are changing fast on spice side, let's just be a little bit more specific here: spice: 2c3fc80e518 qemu: qemu-2.4.1-9.fc23 Sorry for the lack of information. * Guest was Fedora 23 * Not 100% reproducible but quite often Steps: 1) Connect to the Guest 2) Start a file transfer (I often do with a ISO so I have time to kill the agent) 3) Kill the spice-vdagentd spice-server might crash as soon as you kill the agent. Calls to red_char_device_write_buffer_get can return NULL (this is confirmed by the "token violation: dev 0x5598a945d150 client 0x5598a949f780"). Not all paths in spice-server check this. This in the agent is due to recent changes when agent is shutdown not resetting the CharDevice (previously destroyed). Discussed with Uri about doing a "soft reset" instead of not resetting the state at all. Note that red_char_device_write_buffer_get can return NULL in case of flow control enabled. For the agent (see red_char_device_client_add calls in reds.c) flow control is enabled so this probably is not a regression but more a path more stressed (so some change that make this issue more probable). Posted a patch at https://lists.freedesktop.org/archives/spice-devel/2016-May/029730.html I merged the patch and now does not crash anymore. However I think would be worth checking if this problem was introduced (a regression) or present even on stable version. Steps I used: - client fedora 24 with master (5d2fb6a89745767ad22ec60d4aa099e2301ca606) - guest rhel7 - graphical login into guest - start transferring - kill spice-vdagend (I used a ssh root console) - attempt to copy file again (daemon still stopped, same logged in graphic terminal) Problem introduced in 0.13.1, patch 1cec1c5118b65124de6bc6f984f376ff4e297bfb. Was possible even before using old spice-gtk clients which do not implement AGENT_CONNECTED_TOKENS message. The CharDevice lifespan was changed so the error in current code, with old code the char device was destroyed when daemon was killed so the code was never reaching the path which crashed. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.