2016-03-10 20:01 GMT+01:00 Maksim Ivanov <[email protected]>: > Hello all, >
Hello Maksim, > > Looks like there is a bug related to the management of the blocking > requests and of their cancellation. > > The reproduce steps are the following. Two threads: thread 1 and > thread 2. Thread 2 calls SCardGetStatusChange and blocks (with waiting > for some event X). Thread 1 calls SCardCancel. Thread 2 unblocks from > SCardGetStatusChange due to the cancellation, and starts issuing other > PC/SC-Lite API calls. After that, something that triggers the event X > happens. After that the PC/SC-Lite API calls that thread 2 is making > start to break (they return inconsistent results). > > The underlying reason is that cancellation in the current > implementation of the PC/SC-Lite service does not unsubscribe the > client from the list of clients waiting for events. So, when the event > finally occurs, the event response is written into the client's > socket, even if the cancellation had already happened before. Putting > unexpected data into the socket shifts the responses of all further > PC/SC-Lite API calls made by that client. > > If the analysis above is correct, then the correct fix would be > probably just adding a "EHTryToUnregisterClientForEvent(fd)" statement > into the handler of the SCARD_CANCEL message in function ContextThread > (file winscard_svc.c). > You are right. Fixed in 57b0ba5a200bcbf1c489d39261340324392a8e8a Thanks for the analysis and proposed patch. Please tell me when you have finished your code review so I can publish a new version of pcsc-lite with all the fixes :-) Bye -- Dr. Ludovic Rousseau
_______________________________________________ Pcsclite-muscle mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
