JDK-6963006 : smartcardio is not mt safe - javax.smartcardio.CardException: wait mismatch
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.smartcardio
  • Affected Version: 6u20
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2010-06-22
  • Updated: 2012-10-23
  • Resolved: 2011-04-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u25-rev b21Fixed 7u2Fixed
Description
When trying to check from a thread whether a smartcard has been already
removed while a read/write operation is taking place in another thread
the following exception occurs:

   javax.smartcardio.CardException: wait mismatch
      at sun.security.smartcardio.TerminalImpl.waitForCard(TerminalImpl.java:103)
      at sun.security.smartcardio.TerminalImpl.waitForCardAbsent(TerminalImpl.java:120)
      at TerminalImplExample.run(TerminalImplExample.java:116)

This is an exception which should never happen, please see the source code
of waitForCard() in 
/ws/j2se/src/share/classes/sun/security/smartcardio/TerminalImpl.java

            // should never happen
            if (wantPresent != present) {
                throw new CardException("wait mismatch");

Since it does happen, I'd consider this a bug. A test case is available.
See the attached zip file TerminalImplExample.zip. It requires a card reader.

The reason why the exception occured is that waitForCard() is not prepared to 
handle other card state changes than SCARD_STATE_PRESENT = 0x0020;
With the test case we can see that for example 0x0122 occurs, which means
CHANGED PRESENT INUSE.

Comments
SUGGESTED FIX Code review request: http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=3927 Putback request: https://jetsvr.sfbay.sun.com:8443/BugApproval/ViewDetail.jsp?index=10458&mode=view
03-02-2011

EVALUATION comments from PDE review on the fix listed: 1. I think the String[] "SCARD_STATES" and probably also the dumpStatus(int) method belongs to the PCSC class better. 2. The dumpStatus(int) calls should be controlled by a system property setting. Normally, debug info like this are disabled by default. 3. Some indentation doesn't look right? For example, line 108-110 shouldn't have the same indentation? 4. The way remaining timeout is calculated on line 111 doesn't look right. The way you calculate it would lead to earlier timeout. Detailed description is in the Activites section
19-11-2010