On Jul 19, 2013, at 10:31 PM, Nathan Hjelm wrote:
> It might be sufficient to check if the list head is null before trying to
> remove the transfer from the list since the transfer is not on a list when it
> completes. Try adding the check:
>
> if (itransfer->list->list_head)
err,
if (itran
It might be sufficient to check if the list head is null before trying to
remove the transfer from the list since the transfer is not on a list when it
completes. Try adding the check:
if (itransfer->list->list_head)
on lone 1534 of io.c before:
list_del(&itransfer->list);
And let me know i
Hi,
On 07/19/2013 11:06 AM, Hans de Goede wrote:
> Hi All,
>
> I had some inspiration this morning how to fix the deadlock Chris Dickens
> found as a result of the bugreport I forwarded.
>
> So here is a fix for it. I've asked the bug-reporter to test, see:
> https://bugzilla.redhat.com/show_bug.c
To ensure that it is stopped before we continue (and if later libusb
gets re-initialized start another thread).
Signed-off-by: Hans de Goede
---
libusb/os/linux_netlink.c | 1 +
libusb/version_nano.h | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/libusb/os/linux_netlin
Using one lock for this is a bad idea, as we should not be holding any
locks used by the hotplug thread when trying to stop otherwise the stop
function may wait indefinetely in pthread_join, while the event-thread
is waiting for the lock the caller of the stop function holds.
Using 2 separate lock
Hi All,
I had some inspiration this morning how to fix the deadlock Chris Dickens
found as a result of the bugreport I forwarded.
So here is a fix for it. I've asked the bug-reporter to test, see:
https://bugzilla.redhat.com/show_bug.cgi?id=985484
While writing this, I noticed that the netlink c
