Hi Sebastian, On 2012.07.03 15:35, sebasti...@gmx-topmail.de wrote: > I encountered an issue using pcsc-lite and libusb on Ubuntu 10.04 LTS. > Now and then libusb segfaults and causes pcscd to crash. > > The error occurred with libusb-1.0-0 (1.0.8), so I updated libusb-1.0-0 and > libusb-1.0-0-dev to 1.0.11 (libusbx) a few days ago
For the record, libusbx 1.0.12 is the latest, and was released a few weeks ago. However, I don't think any of the fixes we applied between 1.0.11 and 1.0.12 should have much impact on your issue, though 1.0.12 does improve the logging facility. Of course, if you are using the standard package distribution media, there will always be some delay between a new libusbx release, and the time it becomes available as a distro package. If needed, you can download the 1.0.12 source tarball from https://sourceforge.net/projects/libusbx/files/latest/download?source=files > hoping the issue was fixed meanwhile. Unfortunately it happened again. > > I tried to reproduce the failure on my testing environment while pcscd was > running in gdb, but I was not able to trigger it. > > The only output I'm able to provide: > [syslog – libusb 1.0.8] > kernel: [358812.500109] show_signal_msg: 18 callbacks suppressed > kernel: [358812.500124] pcscd[907]: segfault at 8 ip 00fd12f8 sp b6f2b030 > error 4 in libusb-1.0.so.0.0.0[fcd000+d000] > > [syslog – libusbx 1.0.11] > kernel: [144649.500131] show_signal_msg: 9 callbacks suppressed > kernel: [144649.500144] pcscd[898]: segfault at 8 ip 00fbfac8 sp b6f02030 > error 4 in libusb-1.0.so.0.1.0[fbb000+e000] > > The pcsc-daemon loads at startup by executing the start script > /etc/init.d/pcscd. This is going to be tough to troubleshoot without data on what is occurring at the time of the crash. One way or another, we're going to need some logging output from libusbx, but of course, depending on how much USB traffic pcscd and how long it needs to run before observing the crash, the volume of logging output might be prohibitive. Provided pcscd will log stderr output from libusbx, that the volume of USB traffic is not too prohibitive, and that you can be alerted and act on a crash in a matter of hours, here's what I would do: * using the 1.0.12 libusbx source tarball, configure libusbx with --enable-debug-log, then compile and install it on your system * provided you use an advanced syslog facility, such as rsyslog rather than the old and limited syslogd, set up a filter to send all the output of pcscd to /var/log/pcscd.log or something. With rsyslog, you would add the following near the top of your rsyslog.conf: :msg, startswith, "pcscd" /var/log/pcscd.log & ~ * setup log rotation of pcscd.log to one hour (have a look at the content of your /etc/logrotate.d for inspiration on how to create an entry for /var/log/pcscd.log). * As soon as you are aware of another crash, hopefully within 4 hours, make sure you create a backup copy of all the rotated pcscd logs for analysis. Then try to locate and send us the part that occurs right before the crash. Now it is possible that even 4 hours worth of debug logs may be too voluminous (there should be a lot of data in there - if you don't see any, then pcscd may be dropping stderr output), or that the result of all this logging has a noticeable impact on performance/access speeds, or that the issue does not occur at all with debug logging turned on. If that's the case, you can try reducing the log level to INFO rather than DEBUG, as it may still help us get some data as to what occurs around the time of the crash. For that, you should remove the --enable-debug-log when compiling libusbx and then, in /etc/init.d/pcscd, set the environmental variable LIBUSB_DEBUG to 3 (by adding "export LIBUSB_DEBUG=3" at the top of your file). Note that we could probably also use this approach to turn debug logging on without having to recompile with --enable-debug-log (provided you are using libusbx 1.0.12 - this won't work with 1.0.11), by setting LIBUSB_DEBUG to 4. However I'm not sure how much a daemon would read into environment variables, which is why using --enable-debug-log is the safer bet. Is that a troubleshooting approach you think you can go with? Regards, /Pete ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
