Hi,

I have identified the problem. When libusb_exit() is called, the linux
backend will acquire the linux_hotplug_lock before calling
linux_stop_event_monitor(). In this user's particular case, it looks like
the event monitor thread is seeing activity from udev and then tries to
acquire the linux_hotplug_lock, blocking because the lock was taken by the
backend. In linux_udev_stop_monitor(), pthread_cancel() is called to cancel
the event monitor thread, however pthread_mutex_lock() is not a
cancellation point. Therefore there is deadlock when pthread_join() is
called.

Regards,
Chris


On Wed, Jul 17, 2013 at 11:01 AM, Hans de Goede <hdego...@redhat.com> wrote:

> Hi all,
>
> I'm going on vacation for a week starting tomorrow so I don't have time to
> look into this myself atm. If anyone has any clues / ideas as to what is
> going
> on here, you're insight is appreciated.
>
> Regards,
>
> Hans
>
>
> -------- Original Message --------
> Subject: [Bug 985484] New: Deadlock in linux_udev_event_thread_main at
> os/linux_udev.c:153
> Date: Wed, 17 Jul 2013 15:17:12 +0000
> From: bugzi...@redhat.com
> To: hdego...@redhat.com
>
> https://bugzilla.redhat.com/show_bug.cgi?id=985484
>
>              Bug ID: 985484
>             Summary: Deadlock in linux_udev_event_thread_main at
>                      os/linux_udev.c:153
>             Product: Fedora
>             Version: rawhide
>           Component: libusbx
>            Severity: unspecified
>            Priority: unspecified
>            Assignee: hdego...@redhat.com
>            Reporter: manisan...@gmail.com
>          QA Contact: extras...@fedoraproject.org
>                  CC: co...@gnome.eu.org, hdego...@redhat.com,
>                      jv+fed...@fcelda.cz, novyjindr...@gmail.com,
>                      rhb...@n-dimensional.de
>
> Created attachment 774819
>    --> https://bugzilla.redhat.com/attachment.cgi?id=774819&action=edit
> Backtrace
>
> Description of problem:
> Since upgrading to libusbx-1.0.16-1.fc20.x86_64, upowerd occasionally hangs
> (leading for instance to most KDE applications suffering a 25sec startup
> delay,
> until the dbus call to upowerd times out). Retrieving a backtrace from
> upowerd
> shows that the culprit appears to be libusbx. Backtrace is attached.
>
> Version-Release number of selected component (if applicable):
> libusbx-1.0.16-1.fc20.x86_64
>
> How reproducible:
> Occasionally
>
> Steps to Reproduce:
> 1. Difficult, appears more or less daily, possibly related to events such
> as
> suspend/resume.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.
>
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> libusbx-devel mailing list
> libusbx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Reply via email to