MyFaces Core
  1. MyFaces Core
  2. MYFACES-3024

MyFaces hangs when converting 2.2250738585072012e-308

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0.4
    • Component/s: None
    • Labels:
      None

      Description

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

      Nice! and it even works with JSF

      Looking at the MyFaces (double) converter, I see "Double.valueOf()"
      Now, I did a quick check, with Trinidad (disabled client-side validation) and MyFaces (since Trinidad calls super.getAsObject()).

      Entering "2.2250738585072012e-308" into a field, that has a double converter is keeping my JVM really busy !
      Sweet!

        Issue Links

          Activity

          Hide
          Matthias Weßendorf added a comment -

          I am not (yet) sure if the above "string" is the only bad boy - or if there are slightly different variations of it .....

          Show
          Matthias Weßendorf added a comment - I am not (yet) sure if the above "string" is the only bad boy - or if there are slightly different variations of it .....
          Hide
          Werner Punz added a comment -

          If it was the only bad boy we easily can work around that jvm bug, if not, oh well...

          For the time being I would recommend to splice that bad boy into two smaller numbers and then sum them up on the float side.

          Show
          Werner Punz added a comment - If it was the only bad boy we easily can work around that jvm bug, if not, oh well... For the time being I would recommend to splice that bad boy into two smaller numbers and then sum them up on the float side.
          Hide
          Werner Punz added a comment -

          Since you can shoot a site out of existence by pushing this into a field which does the double conversion of a field, I would raise this bug to critical.

          Show
          Werner Punz added a comment - Since you can shoot a site out of existence by pushing this into a field which does the double conversion of a field, I would raise this bug to critical.
          Hide
          Werner Punz added a comment -

          raising the priority to critical

          Show
          Werner Punz added a comment - raising the priority to critical
          Hide
          Mark Struberg added a comment -

          I think we can fix this pretty easily. As far as I know this is the only value which got found causing this problem. I think we can just hardcode a fix in the converter, can't we?

          Btw, there are a few other (already fixed) issues since our last release which would justify shipping a new build really soon.

          Show
          Mark Struberg added a comment - I think we can fix this pretty easily. As far as I know this is the only value which got found causing this problem. I think we can just hardcode a fix in the converter, can't we? Btw, there are a few other (already fixed) issues since our last release which would justify shipping a new build really soon.
          Hide
          Matthias Weßendorf added a comment -

          Yes! The sooner - the better!!

          Show
          Matthias Weßendorf added a comment - Yes! The sooner - the better!!
          Hide
          Andy Schwartz added a comment -

          There is an addendum to the original article that mentions that equivalent forms of the same value also trigger the problem:

          > As pointed out in the comments below, equivalent forms of the number
          > cause the problem as well; examples:
          >
          > 0.00022250738585072012e-304 (decimal point placement)
          > 00000000002.2250738585072012e-308 (leading zeros)
          > 2.225073858507201200000e-308 (trailing zeros)
          > 2.2250738585072012e-00308 (leading zeros in the exponent)
          > 2.2250738585072012997800001e-308 (superfluous digits beyond digit 17)

          This makes a robust fix more difficult.

          Show
          Andy Schwartz added a comment - There is an addendum to the original article that mentions that equivalent forms of the same value also trigger the problem: > As pointed out in the comments below, equivalent forms of the number > cause the problem as well; examples: > > 0.00022250738585072012e-304 (decimal point placement) > 00000000002.2250738585072012e-308 (leading zeros) > 2.225073858507201200000e-308 (trailing zeros) > 2.2250738585072012e-00308 (leading zeros in the exponent) > 2.2250738585072012997800001e-308 (superfluous digits beyond digit 17) This makes a robust fix more difficult.
          Hide
          Werner Punz added a comment -

          Actually there seems to be a certain digit pattern in every of those numbers, 2250738585072012, with a leading 2 as first non zero digit my personal guess is the workaround fix
          for this issue is to break this pattern one way or the other and split it into two separate values which then should be readded on native double level.

          Show
          Werner Punz added a comment - Actually there seems to be a certain digit pattern in every of those numbers, 2250738585072012, with a leading 2 as first non zero digit my personal guess is the workaround fix for this issue is to break this pattern one way or the other and split it into two separate values which then should be readded on native double level.
          Hide
          Mark Struberg added a comment -

          I'll go on with kind of pragmatism I saw that Mark Thomas already fixed this issue in tomcat, so I will just look at his code and reuse the parts he did. Think that is the best thing we can do quickly.

          Show
          Mark Struberg added a comment - I'll go on with kind of pragmatism I saw that Mark Thomas already fixed this issue in tomcat, so I will just look at his code and reuse the parts he did. Think that is the best thing we can do quickly.
          Hide
          Matthias Weßendorf added a comment -

          Tomcat fixed it in their src; we could look there:
          https://twitter.com/theapachetomcat/status/33771766316793856

          Show
          Matthias Weßendorf added a comment - Tomcat fixed it in their src; we could look there: https://twitter.com/theapachetomcat/status/33771766316793856
          Hide
          Mark Struberg added a comment -
          Show
          Mark Struberg added a comment - took me a while to figure where this got fixed. Finally found it listed on http://tomcat.apache.org/security-7.html Here is the respective commit: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Request.java?r1=1066244&r2=1066243&pathrev=1066244
          Hide
          Matthias Weßendorf added a comment -

          Go!

          Show
          Matthias Weßendorf added a comment - Go!
          Hide
          Mark Struberg added a comment -

          first need to fully understand what they did
          Off to the supermarket before that...

          Show
          Mark Struberg added a comment - first need to fully understand what they did Off to the supermarket before that...
          Hide
          Mark Struberg added a comment -

          I fear that the tomcat fix will not help us. We really need to convert whereas tomcat just needed to fix a very specific Locale quality sorting problem.

          Show
          Mark Struberg added a comment - I fear that the tomcat fix will not help us. We really need to convert whereas tomcat just needed to fix a very specific Locale quality sorting problem.
          Hide
          Mark Struberg added a comment -

          oki fixed by first removing all dots and then parsing for 22250738585072012. In this case I return 0.0d

          Since I only do all this stuff if the value.length is > 23 this should not affect the performance for normal use cases.

          Show
          Mark Struberg added a comment - oki fixed by first removing all dots and then parsing for 22250738585072012. In this case I return 0.0d Since I only do all this stuff if the value.length is > 23 this should not affect the performance for normal use cases.
          Hide
          Mark Struberg added a comment -

          fixed in DoubleConverter.java. Please review and if needed also add further tests to DoubleConverterTest.java!

          Show
          Mark Struberg added a comment - fixed in DoubleConverter.java. Please review and if needed also add further tests to DoubleConverterTest.java!
          Hide
          Brian Tinnel added a comment -

          Just FYI, The problem occurs for any number supplied in the range of 2^(-1022) – 2^(-1075) and 2^(-1022) – 2^(-1076). The analysis above states that superfluous characters after the 17th digit do not matter and included an example of 2.2250738585072012497800001e-308 , however the extra characters do matter, it is just that the example is not in the range that causes the issue to happen. Try values like 2.2250738585072012497800001e-308 or 2.2250738585072011997800001e-308 that are within the range and the same looping condition will occur.

          Show
          Brian Tinnel added a comment - Just FYI, The problem occurs for any number supplied in the range of 2^(-1022) – 2^(-1075) and 2^(-1022) – 2^(-1076). The analysis above states that superfluous characters after the 17th digit do not matter and included an example of 2.2250738585072012497800001e-308 , however the extra characters do matter, it is just that the example is not in the range that causes the issue to happen. Try values like 2.2250738585072012497800001e-308 or 2.2250738585072011997800001e-308 that are within the range and the same looping condition will occur.

            People

            • Assignee:
              Mark Struberg
              Reporter:
              Matthias Weßendorf
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development