[Pcsclite-muscle] Bug with SCardCancel followed by new requests on the waiting thread

[Ludovic Rousseau]

2016-03-10 20:01 GMT+01:00 Maksim Ivanov <emaxx at google.com>:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pcsclite-muscle/attachments/20160311/30ac4f61/attachment-0001.html>