StackOverflowError - Java 9 Build 181 (original) (raw)

Tom Hood tom.w.hood at gmail.com
Wed Sep 20 21:14:33 UTC 2017

Sean,

I'll add those lines to the lib/security/default.policy file as you suggested. I left the app running overnight and came in this morning and it was stuck in the infinite recursion loop again. I'll leave it running tonight as well with the default.policy change.

How do I set java.security.debug=all within the jnlp? I tried several things, but none worked.

Then I tried setting it as a property in the jnlp:

I also tried removing the jnlp prefix from the property name:

Then I tried setting it at the start of main with Security.setProperty("java.security.debug", "all") as well as System.setProperty("java.security.debug", "all"). No luck.

Then I tried wrapping javaws in a windows batch file with the following line and selecting the batch file when firefox asks for the program to open the jnlp with:

C:"Program Files"\Java\jre9b181\bin\javaws -J*-Djava.security.debug=all* %1

which also didn't work.

-- Tom

On Wed, Sep 20, 2017 at 12:56 PM, mandy chung <mandy.chung at oracle.com> wrote:

FYI. jdk.javaws is granted with AllPermissions in conf/security/javaws.policy. Maybe javaws.policy is not augmented to the security policy at runtime?

Mandy

On 9/20/17 12:45 PM, Sean Mullan wrote: Tom,

Try adding the following lines to the lib/security/default.policy file in your JDK installation: grant codeBase "jrt:/jdk.javaws" { permission java.security.AllPermission; }; I have a hunch that permissions are not being granted to the jdk.javaws module before it needs them. If that fixes the issue (or you don't see it for a few days), I'll followup and file a bug. Thanks, Sean On 9/19/17 5:55 PM, Tom Hood wrote:

No luck so far reproducing this problem. The two times it happened to me yesterday have both been with Java 9 build 181 and the application has been idle for awhile. I login to our application, execute various features of the application, go to a meeting, return, and then see the java console repeatedly displaying the stack overflow exception. Maybe meetings are bad for Java 9? :-) I think there are some background threads in our application that are waking up periodically and doing "stuff". I don't know what that "stuff" is yet, but that would be my guess at where I will find the code that triggered the overflow.

Assuming I can get our application to the point where I can reproduce the stack overflow, are there particular Java 9 builds that made significant changes to security-relevant code that you'd like me to try? Keep in mind that our app runs on a network not connected to the internet. As it is, I manually typed in the stack trace, so if there's a lot of output I'll have to print it and go through an approval process to show it to you via a scanned pdf. I will continue testing of our app with the security debug turned on so that I'll have the output if it happens again. I also have the logging and tracing enabled in the java control panel. -- Tom

On Tue, Sep 19, 2017 at 12:13 PM, Sean Mullan <sean.mullan at oracle.com_ _<mailto:sean.mullan at oracle.com>> wrote: Cross-posting to security-dev as this is more relevant to that list and bcc-ing core-libs-dev. I think this might be an issue with the JavaWebStart SecurityManager not being granted the proper permissions. It is possible that the deployment policy files are not being loaded or there is some other subtle bootstrapping issue. It should not result in a recursive loop of course, but there may be a workaround. In the meantime, can you send me more information, preferably a test case and a log file with -Djava.security.debug=all enabled? (The latter will help analyze the recursion and see what security checks are failing and for which ProtectionDomains). Also, have you tested this on builds earlier than b181? Thanks, Sean On 9/19/17 2:53 PM, Tom Hood wrote: I should add that we have not modified or overridden any policy files. Also, we are not using a custom security manager. On Tue, Sep 19, 2017 at 11:52 AM, Tom Hood <tom.w.hood at gmail.com_ _<mailto:tom.w.hood at gmail.com>> wrote: Hi, I hit an infinite recursion loop probably related to PolicyFile that exists in Java 9 build 181 for windows 64-bit. It might be related to JDK-8077418 <https://bugs.openjdk.java.net/browse/JDK-8077418_ _<https://bugs.openjdk.java.net/browse/JDK-8077418>> I haven't tracked down what is causing our webstart app to hit this problem yet, but I thought I would let you know sooner than later. Also, it probably is not a problem for our particular application as I should be able to set the security manager to null which I think/hope will bypass this issue. I will try today to reproduce it in our app so I can confirm if setting security manager to null will work for us. The stack looks like the following: (with many repeat stacks omitted) Exception in thread "AWT-EventQueue-2" java.lang.StackOverflowError at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/sun.security.provide r.PolicyFile.getPermissions(Po licyFile.java:1135) at java.base/sun.security.provide r.PolicyFile.getPermissions(Po licyFile.java:1082) at java.base/sun.security.provide r.PolicyFile.implies(PolicyFil e.java:1038) at java.base/java.security.provid er.ProtectionDomain.implies(Pr otectionDomain.java:323) at java.base/java.security.provid er.ProtectionDomain.impliesWit hAltFilePerm(ProtectionDomain.java:355) at java.base/java.security.provid er.AccessControlContext.checkP ermission(AccessControlContext.java:450) at java.base/java.security.provid er.AccessController.checkPermi ssion(AccessController.java:895) at java.base/java.lang.SecurityMa nager.checkPermission(Security Manager.java:558) at jdk.javaws/com.sun.javaws.secu rity.JavaWebStartSecurity.chec kPermission(JavaWebStartSecurity.java:237) at java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:897) at java.base/java.io.File.isDirectory(File.java:845) at java.base/sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:299) at java.base/sun.security.provide r.PolicyFile.canonicalizeCodeb ase(PolicyFile.java:1665) at java.base/sun.security.provide r.PolicyFile.access$700(Policy File.java:263) at java.base/sun.security.provider.PolicyFile$7.run(PolicyFile.java:1139) at java.base/sun.security.provider.PolicyFile$7.run(PolicyFile.java:1136) **** and again **** at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/sun.security.provide r.PolicyFile.getPermissions(Po licyFile.java:1135) at java.base/sun.security.provide r.PolicyFile.getPermissions(Po licyFile.java:1082) at java.base/sun.security.provide r.PolicyFile.implies(PolicyFil e.java:1038) at java.base/java.security.provid er.ProtectionDomain.implies(Pr otectionDomain.java:323) at java.base/java.security.provid er.ProtectionDomain.impliesWit hAltFilePerm(ProtectionDomain.java:355) at java.base/java.security.provid er.AccessControlContext.checkP ermission(AccessControlContext.java:450) at java.base/java.security.provid er.AccessController.checkPermi ssion(AccessController.java:895) at java.base/java.lang.SecurityMa nager.checkPermission(Security Manager.java:558) at jdk.javaws/com.sun.javaws.secu rity.JavaWebStartSecurity.chec kPermission(JavaWebStartSecurity.java:237) at java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:897) at java.base/java.io.File.isDirectory(File.java:845) at java.base/sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:299) at java.base/sun.security.provide r.PolicyFile.canonicalizeCodeb ase(PolicyFile.java:1665) at java.base/sun.security.provide r.PolicyFile.access$700(Policy File.java:263) at java.base/sun.security.provider.PolicyFile$7.run(PolicyFile.java:1139) at java.base/sun.security.provider.PolicyFile$7.run(PolicyFile.java:1136) **** above lines start the stack that repeats until overflow **** at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/sun.security.provide r.PolicyFile.getPermissions(Po licyFile.java:1135) at java.base/sun.security.provide r.PolicyFile.getPermissions(Po licyFile.java:1082) at java.base/sun.security.provide r.PolicyFile.implies(PolicyFil e.java:1038) -- Tom

-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170920/0a5aceba/attachment.htm>

More information about the security-dev mailing list