Description of problem: Forwarded HOST USB DEVICE to Guest Windows VM using virt-manager's "Redirect USB Device" feature. Version-Release number of selected component: virt-manager-1.1.0-5.git310f6527.fc21 Additional info: reporter: libreport-2.3.0 backtrace_rating: 4 cmdline: /usr/bin/python2 -tt /usr/share/virt-manager/virt-manager crash_function: libusb_get_next_timeout executable: /usr/bin/python2.7 kernel: 3.19.4-200.fc21.x86_64 runlevel: N 5 type: CCpp uid: 1000 var_log_messages: [System Logs]:\n-- Logs begin at Mon 2015-04-06 16:32:25 PDT, end at Wed 2015-04-29 11:07:33 PDT. -- Truncated backtrace: Thread no. 1 (6 frames) #0 libusb_get_next_timeout at io.c:2387 #1 get_next_timeout at io.c:2113 #2 libusb_handle_events_timeout_completed at io.c:2163 #3 libusb_handle_events at io.c:2250 #4 spice_usb_device_manager_usb_ev_thread at usb-device-manager.c:1184 #5 g_thread_proxy at gthread.c:764
Created attachment 1020290 [details] File: backtrace
Created attachment 1020291 [details] File: cgroup
Created attachment 1020292 [details] File: core_backtrace
Created attachment 1020293 [details] File: dso_list
Created attachment 1020294 [details] File: environ
Created attachment 1020295 [details] File: exploitable
Created attachment 1020296 [details] File: limits
Created attachment 1020297 [details] File: maps
Created attachment 1020298 [details] File: open_fds
Created attachment 1020299 [details] File: proc_pid_status
This may be a libusbx bug... backtrace is mostly in that space. And there's hits from other projects that look similar: https://bugzilla.redhat.com/show_bug.cgi?id=1122757 https://bugzilla.redhat.com/show_bug.cgi?id=1009644
FWIW faf has 60 hits on this, and a few more with those other bugs
*** Bug 1239271 has been marked as a duplicate of this bug. ***
So faf is up to 550 hits, from f21 to f23. Hans, any ideas or debugging tips here?
Hit this bug, had a usb drive forwarded to a local vm, shut that vm down, switched to a remote one and then removed the usb. Haven't managed to reproduce this
Hi, (In reply to Andrew Cook from comment #15) > Hit this bug, had a usb drive forwarded to a local vm, shut that vm down, > switched to a remote one and then removed the usb. > > Haven't managed to reproduce this This may be fixed by this commit: https://github.com/libusb/libusb/commit/9b2c8abf134b96b6c1798615e0ed17991b8c0692 I hope there will be a 1.0.20 libusb release soon-ish, once Fedora moves to that we will have this fix included.
*** Bug 1262412 has been marked as a duplicate of this bug. ***
Looks like libusb 1.0.20 is out not: https://github.com/libusb/libusb/releases/tag/v1.0.20
*** Bug 1267649 has been marked as a duplicate of this bug. ***
hans do you plan on doing f21 and f22 builds of 1.0.20? there's still lots of faf hits rolling in
(In reply to Cole Robinson from comment #20) > hans do you plan on doing f21 and f22 builds of 1.0.20? there's still lots > of faf hits rolling in Not all the bugfixes in libusb-1.0.20 are exactly trivial, so I'm not entirely sure if doing a 1.0.20 build for f22 is a good idea. f21 definitely seems like a bad idea. Can anyone on this bugs Cc reliably reproduce the problem ? If so then I can provide a test-build and if that helps we can try doing a libusb-1.0.20 for f22 and leaving it in updates-testing for a good long while.
Since the FAF hits still keep coming in, including for F23 which has libusb-1.0.20 I've decided to take another look, and it looks like this is not a libusb problem at all, but rather a spice-gtk or virt-manager problem -> changing component back to virt-manager. Looking closer at the backtrace attached to this bug, the following stands out: #2 0x00007f27e9eb1b37 in libusb_handle_events_timeout_completed (ctx=0x407285b120000000, Look at the libusb_context pointer being passed in, it has bit 62 set, and does not look like any other pointers in the backtrace, so I believe that the pointer has been corrupted, either by spice-gtk, or by something going wrong in virt-manager. This also matches with where the crash is, it is at the line: if (usbi_using_timerfd(ctx)) Which is the first line encountered in the call-path following libusb_handle_events() which actually derefs ctx. Note that the attached backtrace actually has 2 spice_usb_device_manager_usb_ev_thread () instances running, this is normal if there is more then 1 spice connection active, which is not unlikely when using virt-manager, the second thread has this call to libusb_handle_events : #3 0x00007f27e9eb1bd3 in libusb_handle_events_timeout_completed (ctx=0x198ee20, tv=tv@entry=0x7f280649df00, completed=completed@entry=0x0) at io.c:2174 Look at the completely different "range" of the pointers being passed in here. I guess we need to try and figure out a way to reproduce this and then debug it futher. Has anyone tried reproducing this by connecting to 2 spice enabled vms in virt-manager and then doing usb-redirection (maybe try redirecting a device / 2 different devices in both at the same time) ?
Just had a go at reproducing with virt-manager, but no luck from me. Tried two open spice VMs, attaching devices to both, closing and reopening the console window, heavy USB traffic, but no crash from me. Anyone on this bug that sees this crash regularly? Are multiple VMs at play? Are you attaching multiple USB devices? Anything pertinent to add? Adding teuf and elmarco too incase they have any input from the spice side. For context this virt-manager+spice+usb crasher has been around for a while and racked up almost 3000 hits in faf
Okay I might have found some part of this issue. virt-manager crashed on shutdown after all that usb tweaking but the crash isn't consistent for me. However: run virt-manager --debug, open a spice VM with virt-manager, File->Redirect USB..., attach a device, then close the USB dialog, and then close the virt-manager console window, and you'll see on stderr: (virt-manager:29367): GSpice-CRITICAL **: spice_usb_device_manager_finalize: assertion 'priv->event_thread == NULL' failed Seems consistently reproducible. If you uncheck the USB device via the dialog first, then close the virt-manager window, the warning doesn't trigger. Looking at spice-gtk code a bit, it looks like this practically means that there's multiple threads left stranded, all accessing the same private data, so not surprising if this can lead to crashes. virt-viewer doesn't seem to be affected but it doesn't look like it even hits the _dispose path via my exploration of the code. So moving to spice-gtk for now since it seems like there's some missing cleanup at play here
Hmm, looking at the code, it seems the warning could mean that priv->event_thread_run is TRUE in _finalize , which in turns means unbalanced spice_usb_device_manager_{start,stop}_event_listening calls. I indeed see 2 start and only one stop through gdb. One comes from usb_device_manager_get()/spice_usb_device_manager_initable_init(), the other from spice_usbredir_channel_open_device(). The matching stop call for spice_usbredir_channel_open_device() is supposed to be in spice_usbredir_channel_disconnect_device(), but in this situation, session is NULL, so we cannot get the associated usb device manager.
Thanks for the reproducer Cole, I'm hoping the series at https://lists.freedesktop.org/archives/spice-devel/2016-June/030564.html will fix this.
spice-gtk-0.32-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-de01d538f0
spice-gtk-0.32-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-de01d538f0
spice-gtk-0.32-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.