StackOverflowError - Java 9 Build 181

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


In case useful, our jnlp file also contains this:
<security>
  <all-permissions/>
</security>


On Wed, Sep 20, 2017 at 2:14 PM, Tom Hood <tom.w.hood at gmail.com> wrote:

> 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.
>
> <j2se version="1.9+" initial-heap-size="32m" max-heap-size="3072m"
>   java-vm-args="*-Djava.security.debug=all* --add-modules=java.corba
> --add-exports=java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED
> --add-exports=java.desktop/sun.swing=ALL-UNNAMED
> --add-exports=java.desktop/sun.awt.shell=ALL-UNNAMED
> --add-opens=java.base/java.lang=ALL-UNNAMED --add-exports=java.desktop/sun
> .awt.image=ALL-UNNAMED"/>
>
> Then I tried setting it as a property in the jnlp:
>
> <property name="jnlp.*java.security.**debug*" value="all"/>
>
> I also tried removing the jnlp prefix from the property name:
>
> <property name="*java.security.debug*" value="all"/>
>
> 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: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20170920/a870e1e4/attachment-0001.html>


More information about the security-dev mailing list