JRuby (please use github issues at http://bugs.jruby.org)
  1. JRuby (please use github issues at http://bugs.jruby.org)
  2. JRUBY-5441

Attempt to create decimal 2.2250738585072012e-308 sends JVM into tight infinite loop

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: JRuby 1.6.4
    • Component/s: Core Classes/Modules
    • Labels:
      None
    • Number of attachments :
      0

      Description

      http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/

      Basically, 2.2250738585072012e-308 in various forms can't be generated.

        Activity

        Hide
        Douglas Campos added a comment -

        this is related to JRUBY-5190, the boundaries that make the to_f => 0.0 behavior circunvent the same infinite loop triggered by this big number

        Show
        Douglas Campos added a comment - this is related to JRUBY-5190 , the boundaries that make the to_f => 0.0 behavior circunvent the same infinite loop triggered by this big number
        Hide
        Charles Oliver Nutter added a comment -

        From the articles about the issue, it seems this has been accepted as a bug with internal bug number 1949967.

        Show
        Charles Oliver Nutter added a comment - From the articles about the issue, it seems this has been accepted as a bug with internal bug number 1949967.
        Hide
        Charles Oliver Nutter added a comment -

        I have a working solution I'm going to commit. There may be improvements suggested by commenters on my blog post:

        http://blog.headius.com/2011/02/working-around-java-doubleparsedouble.html

        Show
        Charles Oliver Nutter added a comment - I have a working solution I'm going to commit. There may be improvements suggested by commenters on my blog post: http://blog.headius.com/2011/02/working-around-java-doubleparsedouble.html
        Hide
        Charles Oliver Nutter added a comment -

        commit 4c712963885c0117b95066d927520a6a738c2a65
        Author: Charles Oliver Nutter <headius@headius.com>
        Date: Wed Feb 2 12:20:05 2011 -0600

        Fix JRUBY-5441: Attempt to create decimal 2.2250738585072012e-308 sends JVM into tight infinite loop

        There were only two places we called Double.parseDouble. I modified both places to use my own logic that splits up the mantissa and exponent and uses BigDecimal math to produce a result.

        Show
        Charles Oliver Nutter added a comment - commit 4c712963885c0117b95066d927520a6a738c2a65 Author: Charles Oliver Nutter <headius@headius.com> Date: Wed Feb 2 12:20:05 2011 -0600 Fix JRUBY-5441 : Attempt to create decimal 2.2250738585072012e-308 sends JVM into tight infinite loop There were only two places we called Double.parseDouble. I modified both places to use my own logic that splits up the mantissa and exponent and uses BigDecimal math to produce a result.
        Hide
        David Lee added a comment -

        Will this be backported to 1.5.6?

        Show
        David Lee added a comment - Will this be backported to 1.5.6?
        Hide
        Hiro Asari added a comment -

        This isn't fixed yet.

        Show
        Hiro Asari added a comment - This isn't fixed yet.
        Hide
        Charles Oliver Nutter added a comment -

        Punting off RC2.

        I tried another attempt at this, by checking whether the normalized string form (produced by BigDecimal.toString just before calling .doubleValue) is .equals to the known bad form. My change just then replaced the doubleValue call with a literal value close to the bad form that's known to parse, and other things failed.

        We'll have to poke around more for a workaround. Nothing so far passes all tests.

        Show
        Charles Oliver Nutter added a comment - Punting off RC2. I tried another attempt at this, by checking whether the normalized string form (produced by BigDecimal.toString just before calling .doubleValue) is .equals to the known bad form. My change just then replaced the doubleValue call with a literal value close to the bad form that's known to parse, and other things failed. We'll have to poke around more for a workaround. Nothing so far passes all tests.
        Hide
        Charles Oliver Nutter added a comment -

        I made another attempt that tries to check if the value is in the proper range, but this version fails other specs that expect specific minimum float values.

        https://gist.github.com/815270

        Show
        Charles Oliver Nutter added a comment - I made another attempt that tries to check if the value is in the proper range, but this version fails other specs that expect specific minimum float values. https://gist.github.com/815270
        Hide
        Charles Oliver Nutter added a comment -

        Oracle has released a hotfix that applies to earlier JDKs as well. http://www.oracle.com/technetwork/java/javase/fpupdater-tool-readme-305936.html

        I expect Apple will get updates released shortly.

        Show
        Charles Oliver Nutter added a comment - Oracle has released a hotfix that applies to earlier JDKs as well. http://www.oracle.com/technetwork/java/javase/fpupdater-tool-readme-305936.html I expect Apple will get updates released shortly.
        Hide
        Hiro Asari added a comment -

        Indeed, Apple's latest JDK contains the fix.

        $ jruby -v -e 'p 2.2250738585072012e-308'
        jruby 1.6.0 (ruby-1.8.7-p330) (2011-04-11 b695384) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_24) [darwin-x86_64-java]
        2.2250738585072e-308
        

        We do still have a pragmatic problem of supporting older versions of JDK.

        Should we incorporate the fix outlined here: http://extremestjython.blogspot.com/2011/02/no-more-java-double-trouble.html

        Show
        Hiro Asari added a comment - Indeed, Apple's latest JDK contains the fix. $ jruby -v -e 'p 2.2250738585072012e-308' jruby 1.6.0 (ruby-1.8.7-p330) (2011-04-11 b695384) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_24) [darwin-x86_64-java] 2.2250738585072e-308 We do still have a pragmatic problem of supporting older versions of JDK. Should we incorporate the fix outlined here: http://extremestjython.blogspot.com/2011/02/no-more-java-double-trouble.html
        Hide
        Charles Oliver Nutter added a comment -

        Yes, I think we should.

        Show
        Charles Oliver Nutter added a comment - Yes, I think we should.
        Hide
        Charles Oliver Nutter added a comment -

        Fixed on master (66b5b33) and jruby-1_6:

        commit 9791492574e39c78e9bc62d9dc71081e2810e2dc
        Author: Charles Oliver Nutter <headius@headius.com>
        Date: Mon Jul 11 19:40:43 2011 -0500

        Fix JRUBY-5541 on older JDKs: Attempt to create decimal 2.2250738585072012e-308 sends JVM into tight infinite loop

        Show
        Charles Oliver Nutter added a comment - Fixed on master (66b5b33) and jruby-1_6: commit 9791492574e39c78e9bc62d9dc71081e2810e2dc Author: Charles Oliver Nutter <headius@headius.com> Date: Mon Jul 11 19:40:43 2011 -0500 Fix JRUBY-5541 on older JDKs: Attempt to create decimal 2.2250738585072012e-308 sends JVM into tight infinite loop Using code from Oti's blog: http://extremestjython.blogspot.com/2011/02/no-more-java-double-trouble.html , which he has released into the public domain.

          People

          • Assignee:
            Charles Oliver Nutter
            Reporter:
            Hiro Asari
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: