groovy
  1. groovy
  2. GROOVY-6246

ResourceBundle.getBundle() freezes on openjdk 1.7.0_25

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Not A Bug
    • Affects Version/s: 2.1.6
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      Linux (Fedora 18 x86_64)
    • Number of attachments :
      0

      Description

      The following line freezes Groovy on openjdk 1.7.0_25, causing 100% CPU load:

      ResourceBundle foo = ResourceBundle.getBundle('foo');
      

      It is working fine with openjdk 1.7.0_9. I could reproduce this bug with various Groovy versions from 1.8 up to 2.1.6, and on two different Fedora 18 machines.

      A java dump delivered this thread stack trace:

      "main" prio=10 tid=0x00007f1014008000 nid=0xd74 runnable [0x00007f101a0cf000]
         java.lang.Thread.State: RUNNABLE
      	at sun.reflect.Reflection.getCallerClass0(Native Method)
      	at sun.reflect.Reflection.getCallerClass(Reflection.java:68)
      	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      	at java.lang.reflect.Method.invoke(Method.java:606)
      	at org.codehaus.groovy.reflection.ReflectionUtils.getCallingClass(ReflectionUtils.java:117)
      	at org.codehaus.groovy.reflection.ReflectionUtils.getCallingClass(ReflectionUtils.java:91)
      	at org.codehaus.groovy.reflection.ReflectionUtils.getCallingClass(ReflectionUtils.java:78)
      	at org.codehaus.groovy.runtime.DefaultGroovyStaticMethods.getBundle(DefaultGroovyStaticMethods.java:231)
      	at org.codehaus.groovy.runtime.DefaultGroovyStaticMethods.getBundle(DefaultGroovyStaticMethods.java:215)
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      	at java.lang.reflect.Method.invoke(Method.java:606)
      	at org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:51)
      	at org.codehaus.groovy.runtime.metaclass.NewStaticMetaMethod.invoke(NewStaticMetaMethod.java:51)
      	at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite$StaticMetaMethodSiteNoUnwrapNoCoerce.invoke(StaticMetaMethodSite.java:148)
      	at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.call(StaticMetaMethodSite.java:88)
      	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
      	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
      	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
      	at Test.run(Test.groovy:1)
      	at groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:257)
      	at groovy.lang.GroovyShell.run(GroovyShell.java:220)
      	at groovy.lang.GroovyShell.run(GroovyShell.java:150)
      	at groovy.ui.GroovyMain.processOnce(GroovyMain.java:588)
      	at groovy.ui.GroovyMain.run(GroovyMain.java:375)
      	at groovy.ui.GroovyMain.process(GroovyMain.java:361)
      	at groovy.ui.GroovyMain.processArgs(GroovyMain.java:120)
      	at groovy.ui.GroovyMain.main(GroovyMain.java:100)
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      	at java.lang.reflect.Method.invoke(Method.java:606)
      	at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:106)
      	at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:128)
      

      Major priority because this bug potentially affects any multilingual Groovy project.

        Issue Links

          Activity

          Hide
          blackdrag blackdrag added a comment -

          if it worked before it is likely that a change in the jdk caused the problem. But I have problems reproducing the issue. Using the oracle jdk7u25 does not show this behavior. Could you try the oracle 7u25 as well?

          Show
          blackdrag blackdrag added a comment - if it worked before it is likely that a change in the jdk caused the problem. But I have problems reproducing the issue. Using the oracle jdk7u25 does not show this behavior. Could you try the oracle 7u25 as well?
          Hide
          blackdrag blackdrag added a comment -

          Another thing to add actually... according to the plans of the jdk people this method will no longer work properly if called from Groovy in the final jdk8 and starting with the next jdk7 update. As it looks now we cannot correct this on our side, since they take away one of the essential toys (Reflection.getCallerClass(int), a sun.* class) for this and there is no replacement. Please use instead a RessourceBundle#getBundle, that has the classloader in the signature (the loader is normally this.class.classLoader).

          Show
          blackdrag blackdrag added a comment - Another thing to add actually... according to the plans of the jdk people this method will no longer work properly if called from Groovy in the final jdk8 and starting with the next jdk7 update. As it looks now we cannot correct this on our side, since they take away one of the essential toys (Reflection.getCallerClass(int), a sun.* class) for this and there is no replacement. Please use instead a RessourceBundle#getBundle, that has the classloader in the signature (the loader is normally this.class.classLoader).
          Hide
          Richard Körber added a comment -

          Yes, it's working with Oracle JDK 1.7.0_25, so it seems to be an issue with OpenJDK. As a workaround, I have moved the ResourceBundle.getBundle() call to an actual Java class.

          However this bug doesn't seem to worry you too much. Isn't Groovy supposed to run on the JDK reference implementation, and on JDK 8?

          Show
          Richard Körber added a comment - Yes, it's working with Oracle JDK 1.7.0_25, so it seems to be an issue with OpenJDK. As a workaround, I have moved the ResourceBundle.getBundle() call to an actual Java class. However this bug doesn't seem to worry you too much. Isn't Groovy supposed to run on the JDK reference implementation, and on JDK 8?
          Hide
          Cédric Champeau added a comment -

          Richard, be sure we consider all bugs seriously. However, we're kind of helpless with this one, since the JDK guys decided to remove a method that we use internally and for which there is no replacement. We are working hard to find a workaround or make them change their mind, since it's a major breakage for us (it breaks @Grab too!). There are discussions ongoing, but they didn't drive to any acceptable solution so far.

          Show
          Cédric Champeau added a comment - Richard, be sure we consider all bugs seriously. However, we're kind of helpless with this one, since the JDK guys decided to remove a method that we use internally and for which there is no replacement . We are working hard to find a workaround or make them change their mind, since it's a major breakage for us (it breaks @Grab too!). There are discussions ongoing, but they didn't drive to any acceptable solution so far.
          Hide
          Cédric Champeau added a comment -

          Some more news: the bug you are facing is actually a bug in the JDK, which is different from the issue I'm mentionning: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016814

          Anyway, we're still discussing the getCallerClass issue

          Show
          Cédric Champeau added a comment - Some more news: the bug you are facing is actually a bug in the JDK, which is different from the issue I'm mentionning: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016814 Anyway, we're still discussing the getCallerClass issue
          Hide
          Richard Körber added a comment -

          Cedric, thanks for pointing out. An offense was not my intention.

          I was just about to dig deeper into the issue. The sun.reflect.Reflection.getCallerClass() method is obviously still available in 1.7.0_25, but seems to lead into an endless loop now. However, since you mentioned the JDK bug, I think this issue can be closed.

          Show
          Richard Körber added a comment - Cedric, thanks for pointing out. An offense was not my intention. I was just about to dig deeper into the issue. The sun.reflect.Reflection.getCallerClass() method is obviously still available in 1.7.0_25, but seems to lead into an endless loop now. However, since you mentioned the JDK bug, I think this issue can be closed.
          Hide
          blackdrag blackdrag added a comment -

          Richard, is it possible for you to use https://jdk7.java.net/download.html to test 7u40 Build b31 of the open jdk? There is at least one (possibly unrelated) regression bug in the getCallerClass method in u25

          Show
          blackdrag blackdrag added a comment - Richard, is it possible for you to use https://jdk7.java.net/download.html to test 7u40 Build b31 of the open jdk? There is at least one (possibly unrelated) regression bug in the getCallerClass method in u25
          Hide
          Pascal Schumacher added a comment -

          As Cedric said this is a bug in Open JDK 1.7.0_25 so I'm closing this issue.

          Show
          Pascal Schumacher added a comment - As Cedric said this is a bug in Open JDK 1.7.0_25 so I'm closing this issue.

            People

            • Assignee:
              Unassigned
              Reporter:
              Richard Körber
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: