On 28 May 2014 15:30, Aurelien Jarno <aurel...@aurel32.net> wrote: > On Wed, May 28, 2014 at 03:20:24PM +0200, Raphael Geissert wrote: >> On 28 May 2014 15:03, Aurelien Jarno <aurel...@aurel32.net> wrote: >> > On Wed, May 28, 2014 at 12:31:00PM +0200, Raphael Geissert wrote: >> [...] >> > With a backtrace, it will be difficult to debug this kind of problem. >> > You said that the backtrace is not useful with the wheezy -dbg package, >> > but there is not such a package on wheezy... >> >> Good point, perhaps I confused it with the dbg package of one of the >> other libusb*. Will check and get back to you on that.
Actually it's the -dbg in wheezy-backports >> > Could you please provide the backtrace or the core file, so that we can >> > see at least the libusb function where the crash occurs? >> >> Will rebuild with debugging symbols and see what I can get out of it, sure. > > Ok, great. I hope it will give us more details. I rebuilt pcscd and libusb with -O0 -ggdb3 and I still don't get anything useful out of the backtrace, the stack seems to have been corrupted. valgrind's memcheck doesn't show anything interesting, neither does wheezy's helgrind. The strace shows that the thread that segfaults is the one that reads from /sys/bus/usb/devices, the segfault occurs right after its call to poll(2) returns when the device is plugged. ltracing pcscd doesn't help much either, because libusb is dlopen'ed, so it is not seen by ltrace. Looking for conflicting symbols (who knows, just a possibility) between libudev, libusb and libccid, I don't see any. However, I see that newer libusbs call libudev directly, and apparently do some thread handling on its own: pthread_create and pthread_join are now used by libusb (cf. attached nm -D output, with addresses modified for easier diff'ing). Does that give you any hint already? Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net
wheezy.sym
Description: Binary data
wheezybpo.sym
Description: Binary data
