JDK-8077418 : StackOverflowError during PolicyFile lookup
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 8u60,9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-04-10
  • Updated: 2017-12-08
  • Resolved: 2016-06-13
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 8 JDK 9
8u60Fixed 9 b66Fixed
Related Reports
Relates :  
JDK-8058547 - Memory leak in ProtectionDomain cache
Relates :  
JDK-8055753 - Use ConcurrentHashMap to map ProtectionDomain to PermissionCollection
Relates :  
JDK-8061483 - Memory leak in ProtectionDomain cache
Relates :  
JDK-8166366 - StackOverflowError with custom security manager
Relates :  
JDK-8191649 - StackOverFlow caused with custom security manager
Relates :  
JDK-8143222 - StackOverflowError during PolicyFile lookup
Description
StackOverflowError when running nsk/stress/jck60/jck60014:

[2015-05-07T15:37:54.25] java.lang.StackOverflowError
[2015-05-07T15:37:54.25] 	at java.security.AccessController.doPrivileged(Native Method)
[2015-05-07T15:37:54.25] 	at java.io.FilePermission.init(FilePermission.java:204)
[2015-05-07T15:37:54.25] 	at java.io.FilePermission.<init>(FilePermission.java:278)
[2015-05-07T15:37:54.25] 	at java.lang.SecurityManager.checkRead(SecurityManager.java:880)
[2015-05-07T15:37:54.25] 	at java.io.File.isDirectory(File.java:844)
[2015-05-07T15:37:54.25] 	at sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:269)
[2015-05-07T15:37:54.25] 	at sun.security.provider.PolicyFile.canonicalizeCodebase(PolicyFile.java:1715)
[2015-05-07T15:37:54.25] 	at sun.security.provider.PolicyFile.access$700(PolicyFile.java:258)
[2015-05-07T15:37:54.25] 	at sun.security.provider.PolicyFile$5.run(PolicyFile.java:1168)
[2015-05-07T15:37:54.25] 	at sun.security.provider.PolicyFile$5.run(PolicyFile.java:1166)
[2015-05-07T15:37:54.25] 	at java.security.AccessController.doPrivileged(Native Method)
[2015-05-07T15:37:54.25] 	at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1165)
[2015-05-07T15:37:54.25] 	at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1112)
[2015-05-07T15:37:54.25] 	at sun.security.provider.PolicyFile.implies(PolicyFile.java:1066)
[2015-05-07T15:37:54.25] 	at java.security.ProtectionDomain.implies(ProtectionDomain.java:278)
[2015-05-07T15:37:54.25] 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:446)
[2015-05-07T15:37:54.25] 	at java.security.AccessController.checkPermission(AccessController.java:894)
[2015-05-07T15:37:54.25] 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:541)
[2015-05-07T15:37:54.25] 	at javasoft.sqe.tests.api.java.lang.ClassLoader.CustomSecurityManager.checkPermission(CustomSecurityManager.java:60)
[2015-05-07T15:37:54.25] 	at java.lang.SecurityManager.checkRead(SecurityManager.java:880)
[2015-05-07T15:37:54.25] 	at java.io.File.isDirectory(File.java:844)
[2015-05-07T15:37:54.25] 	at sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:269)
[2015-05-07T15:37:54.25] 	at sun.security.provider.PolicyFile.canonicalizeCodebase(PolicyFile.java:1715)
[2015-05-07T15:37:54.25] 	at sun.security.provider.PolicyFile.access$700(PolicyFile.java:258)
[2015-05-07T15:37:54.25] 	at sun.security.provider.PolicyFile$5.run(PolicyFile.java:1168)
[2015-05-07T15:37:54.25] 	at sun.security.provider.PolicyFile$5.run(PolicyFile.java:1166)
[2015-05-07T15:37:54.25] 	at java.security.AccessController.doPrivileged(Native Method)
[2015-05-07T15:37:54.25] 	at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1165)
[2015-05-07T15:37:54.25] 	at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1112)
[2015-05-07T15:37:54.25] 	at sun.security.provider.PolicyFile.implies(PolicyFile.java:1066)
[2015-05-07T15:37:54.25] 	at java.security.ProtectionDomain.implies(ProtectionDomain.java:278)
[2015-05-07T15:37:54.25] 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:446)
[2015-05-07T15:37:54.25] 	at java.security.AccessController.checkPermission(AccessController.java:894)
[2015-05-07T15:37:54.25] 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:541)
[2015-05-07T15:37:54.25] 	at javasoft.sqe.tests.api.java.lang.ClassLoader.CustomSecurityManager.checkPermission(CustomSecurityManager.java:60)
[2015-05-07T15:37:54.25] 	at java.lang.SecurityManager.checkRead(SecurityManager.java:880)
[2015-05-07T15:37:54.25] 	at java.io.File.isDirectory(File.java:844)
...

RULE nsk/stress/jck60/jck60014 StatusError Maximum log length (32MB) exceeded
Comments
I have determined that the fix for JDK-8058547 (Memory leak in ProtectionDomain cache) is the cause of this issue. I had already realized the fix for JDK-8058547 was problematic while working on JEP 232 (Improve Secure Application Performance). Thus, I had removed it as part of one of my changesets for the JEP which has already been integrated into the JDK 9 master in b66: https://bugs.openjdk.java.net/browse/JDK-8055753 I have confirmed that the test in JDK-8077734 no longer fails with StackOverflowError on the latest JDK 9 build. Thus, I am closing this bug as it is no longer an issue on JDK 9. However, it is still a problem on JDK 8u60. The backport should remain open, and the fix is to backout the changes for JDK-8058547. Finally, JDK-8058547 will need to be re-opened and the previous fix will need to be reworked.
05-06-2015
I have a suspicion that this may have been caused by my fix for JDK-8058547 (Memory leak in ProtectionDomain cache), as that fix went into b37 and from the stack it appears that it may not be retrieving a ProtectionDomain that previously would have been cached, thus avoiding the recursive permission check. This whole area though (custom SecurityManager/Policy and recursive permission checks) has long been a problematic area, and I am looking into ways to address this more cleanly. Anyway, I'll first try backing out that fix and see if the problem goes away.
08-05-2015
Reproduces with jdk9-b37, doesn't reproduce with b36. This does not look like a Hotspot issue.
07-05-2015
I'd hand this over to the jck folk as it seems like a test issue to me.
24-04-2015
This seems to happen on all of the platforms, not just embedded. Went back and found failures due to SOE back in November (that's as far as I bothered to look).
23-04-2015
Hard to see how this would be embedded specific. This seems to be an error in the custom security manager - or an error in the way it is used - a checkRead permission check should not lead to a second checkRead permission check in trying to read the policy file. Is there something new about how this test has been run?
22-04-2015
There seems to be infinite recursion in a permissions check: [2015-04-09T18:02:50.49] java.lang.reflect.InvocationTargetException [2015-04-09T18:02:50.59] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [2015-04-09T18:02:50.59] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) [2015-04-09T18:02:50.59] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) [2015-04-09T18:02:50.59] at java.lang.reflect.Method.invoke(Unknown Source) [2015-04-09T18:02:50.59] at nsk.stress.share.StressTest$TestThread.runTest(StressTest.java:756) [2015-04-09T18:02:50.59] at nsk.stress.share.StressTest$TestThread.run(StressTest.java:770) [2015-04-09T18:02:50.70] Caused by: java.lang.StackOverflowError [2015-04-09T18:02:50.70] at java.security.AccessController.doPrivileged(Native Method) [2015-04-09T18:02:50.70] at java.io.FilePermission.init(Unknown Source) [2015-04-09T18:02:50.70] at java.io.FilePermission.<init>(Unknown Source) [2015-04-09T18:02:50.70] at java.lang.SecurityManager.checkRead(Unknown Source) [2015-04-09T18:02:50.70] at java.io.File.isDirectory(Unknown Source) [2015-04-09T18:02:50.70] at sun.net.www.ParseUtil.fileToEncodedURL(Unknown Source) [2015-04-09T18:02:50.70] at sun.security.provider.PolicyFile.canonicalizeCodebase(Unknown Source) [2015-04-09T18:02:50.70] at sun.security.provider.PolicyFile.access$700(Unknown Source) [2015-04-09T18:02:50.70] at sun.security.provider.PolicyFile$5.run(Unknown Source) [2015-04-09T18:02:50.70] at sun.security.provider.PolicyFile$5.run(Unknown Source) [2015-04-09T18:02:50.70] at java.security.AccessController.doPrivileged(Native Method) [2015-04-09T18:02:50.70] at sun.security.provider.PolicyFile.getPermissions(Unknown Source) [2015-04-09T18:02:50.70] at sun.security.provider.PolicyFile.getPermissions(Unknown Source) [2015-04-09T18:02:50.70] at sun.security.provider.PolicyFile.implies(Unknown Source) [2015-04-09T18:02:50.70] at java.security.ProtectionDomain.implies(Unknown Source) [2015-04-09T18:02:50.70] at java.security.AccessControlContext.checkPermission(Unknown Source) [2015-04-09T18:02:50.70] at java.security.AccessController.checkPermission(Unknown Source) [2015-04-09T18:02:50.70] at java.lang.SecurityManager.checkPermission(Unknown Source) [2015-04-09T18:02:50.70] at javasoft.sqe.tests.api.java.lang.ClassLoader.CustomSecurityManager.checkPermission(CustomSecurityManager.java:60) [2015-04-09T18:02:50.70] at java.lang.SecurityManager.checkRead(Unknown Source) [2015-04-09T18:02:50.70] at java.io.File.isDirectory(Unknown Source) ... Notice java.io.File.isDirectory() is causing recursion here. This goes on until there is a StackOverflowError. Also, this happens many times in the log until it fills up with its 32mb max, I think maybe because there are 100 threads that produce this exception.
22-04-2015