-
Bug
-
Resolution: Fixed
-
P4
-
8, 11, 15
-
b15
-
Not verified
Found by TSAN, java.security.Provider$Service.supportsParameter() is racy. We haven't observed any actual bad behavior, but reasoning through it seems like bad behavior is possible.
http://hg.openjdk.java.net/jdk/jdk/file/62b5bfef8d61/src/java.base/share/classes/java/security/Provider.java#l1927
The synchronized block seems to not have any effect on correctness.
Example race:
T1 in hasKeyAttributes() writes true to hasKeyAttributes and fills out supportedFormats/supportedClasses.
T2 in hasKeyAttributes() racily reads hasKeyAttributes as true, but then in supportsKeyFormat() racily reads supportedFormats as null. It can then improperly return false from supportsParameter().
There is no synchronization between T1 and T2 because T2 never does any synchronization, so T2 can read what T1 writes in any order.
http://hg.openjdk.java.net/jdk/jdk/file/62b5bfef8d61/src/java.base/share/classes/java/security/Provider.java#l1927
The synchronized block seems to not have any effect on correctness.
Example race:
T1 in hasKeyAttributes() writes true to hasKeyAttributes and fills out supportedFormats/supportedClasses.
T2 in hasKeyAttributes() racily reads hasKeyAttributes as true, but then in supportsKeyFormat() racily reads supportedFormats as null. It can then improperly return false from supportsParameter().
There is no synchronization between T1 and T2 because T2 never does any synchronization, so T2 can read what T1 writes in any order.