2012/5/27 Martin Vogt <[email protected]>: > On Sun, May 27, 2012 at 3:50 PM, Ludovic Rousseau > <[email protected]> wrote:
>> I have not yet fixed this bug. >> And yes. It is a bit more complex to fix. I don't know yet how I will fix it. > > I looked at the code and added a few printfs. > The sequence seems to be: > HOTPLUG UDEV calls RFRemoveReader -s > [....] > 00000010 readerfactory.c:1009:RFUnInitializeReader() Attempting > shutdown of Aladdin eToken PRO USB 72K Java [Main Interface] 00 00. > 00000013 ifdhandler.c:244:IFDHCloseChannel() > usb:0529/0620:libudev:0:/dev/bus/usb/002/018 (lun: 0) > 00000021 ccid_usb.c:649:WriteUSB() write failed (2/18): -4 No such device > RFUnInitializeReader-1 > 00000026 readerfactory.c:880:RFUnloadReader() Unloading reader driver. > > In between this call starts a new ContexThread: > > 00000105 winscard_svc.c:315:ContextThread() Received command: > DISCONNECT from client 9 > > HOTPLU UDEV ends call RFRemoveReader -e > > Then I have: > > 00073910 winscard.c:796:SCardDisconnect() Lock released > 00000010 winscard.c:820:SCardDisconnect() Active Contexts: 0 > 00000006 winscard.c:821:SCardDisconnect() dwDisposition: 2 > Segmentation fault > > Maybe the hotplug thread can deliver Add/Remove over the SVCServiceRunLoop? > (As far as I understand it, the hotplug mechanism works independently, > and this may be the problem?) You can considerably reduce the time before the crash by adding a sleep(1) in ifdwrapper.c at line 269, just before the call to IFDStatusICC(); The problem is that the reader is removed while another function using the reader is running and after this another function has checked the reader is present. It is a classic TOCTTOU bug [1]. Bye [1] http://en.wikipedia.org/wiki/Time_of_check_to_time_of_use -- Dr. Ludovic Rousseau _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
