Bug 996760

Description of problem:
Since Fedora 19, libusbx's libusb_init() method will spawn a thread in the background to process udev events.  This thread will only be stopped if libusb_close() is called

The libusb usb_init() method calls libusb_init() but libusb's API design offers no way to have libusb_close() called.

Now, libgphoto uses libusb and will dlopen() and dlclose() it. Unfortunately since there is no way to ensure libusb_close() is called, when libgphoto dlcloses the libusb.so library, the thread from libusbx.so will not be stopped. So a thread will remain running, executing code from a memory region that has now been freed. Crash-tastic results ensue.

I don't see a good way to fix this from libusb or libusbx, given the need to preserve the existing API of libusb.

If, however, we link libusb.so using  -znodelete, we will prevent it from ever being unloaded, despite the dlclose() calls. This is not ideal, but better than allowing it to be unloaded which is a guaranteed crash.

Version-Release number of selected component (if applicable):
libusb-0.1.4-1.fc19.x86_64

How reproducible:
Semi-reliable

Steps to Reproduce:
1. Start entangle
2. Connect to a camera
3. Attach to entangle with gdb
4. Run 'thread apply all bt'

Actual results:
Many threads showing bogus stack frames:

Thread 7 (Thread 0x7fffe95da700 (LWP 10821)):
#0  0x0000003428eeab6d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x000000323d60e5f8 in ?? ()
#2  0x0000000000000000 in ?? ()


Expected results:
One thread showing

#0  0x0000003428eeab6d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x000000323d60e5f8 in linux_udev_event_thread_main () from /lib64/libusb-1.0.so.0
#2  0x0000003429207c53 in start_thread (arg=0x7fffeaed8700) at pthread_create.c:308
#3  0x0000003428ef513d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113


Additional info: