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:
Created attachment 786305 [details] Link with -znodelete I've tested the following patch and it solved the crashes I was seeing with libusb when libgphoto is used from the entangle application.
libusb-0.1.5-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/libusb-0.1.5-2.fc19
Package libusb-0.1.5-2.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libusb-0.1.5-2.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-14785/libusb-0.1.5-2.fc19 then log in and leave karma (feedback).
FYI, I have also filed a bug against libgphoto2, suggesting we switch it to buld with libusbx instead of libusb, which would let it directly avoid the flaw in the first place https://bugzilla.redhat.com/show_bug.cgi?id=997880
libusb-0.1.5-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.