Assertion botch: excessivly large digit ???

[vulcand4]

I am getting the following runtime exception in a JSP when I try to print a float:

Assertion botch: excessivly large digit 11


The exception says that it is trying to convert the float to a String and I get the error. I'm not sure what the contents of the float variable are before the exception occurs.
Any help is appreciated.

-Poly

 

[BoulderBum]

Apparently, it's a custom RuntimeException thrown from custom code. Are you using some downloaded tool? The only place I can seem to find the error message is in a bunch of open source formula parsing tools and stuff.

I don't think anyone will be able to help you without more information. What is the class that throws the exception, and what is chunk the code where the exception is thrown?

 

[vulcand4]

I have a float variable called pct.

I then have code in a JSP like the following:

<td>Percentage</td><td><%= pct %></td>

It's the code in red that bombs. It's not custom code, it's standard JSP.

If I try to do a System.out.println(&quot;percentage is: &quot; + pct); It bombs here instead.

The exception always lists a number after it (11 in my case) It almost seems like it assumes 11 is a single digit (which it isn't) and so it chokes.

 

[hologram]

At least somebody else got more or less the same error and reported it to Sun [Jun 19, 2003!]. The bug seems to be in one of the java.lang classes.

http://developer.java.sun.com/developer/bugParade/bugs/4881096.html

Synopsis : Assertion botch: excessivly large digit 20 occurs every second on one box in cluster
Category : java:runtime
Reported Against :  1.3.1_07
Release Fixed :  
State : In progress, bug
Related Bugs :  
Submit Date : Jun 19, 2003 
Description : rather bizarre bug that we're having problems nailing down.

Customer has BEA weblogic running in a cluster with JDK 1.3.1_07.  machines are
the same and configures the same.  Sun Netra T4 (2 X UltraSPARC-III), 2 CPU,
4GB MEM, 2x 36GB disk  Only one of them shows this error.  It used to be a
backup so they weren't too concerned about the exception, but now it's been
moved into production.  This gets thrown once a second.
This shows up in 1.3.1_03 and also 1.3.1_08(only other versions tested)

java.lang.RuntimeException: Assertion botch: excessivly large digit 20
java.lang.RuntimeException: Assertion botch: excessivly large digit 20
        at java.lang.FloatingDecimal.dtoa(FloatingDecimal.java:760)
        at java.lang.FloatingDecimal.<init>(FloatingDecimal.java:500)
        at java.lang.Float.toString(Float.java:124)
        at java.lang.String.valueOf(String.java:2152)
        at java.lang.Float.toString(Float.java:278)
        at weblogic.servlet.logging.TimeLogField.logField(TimeLogField.java:37)
        at weblogic.servlet.logging.ELFLogger.log(ELFLogger.java:138)
        at weblogic.servlet.logging.LogManagerHttp.log(LogManagerHttp.java:324)
        at weblogic.servlet.internal.HttpServer.log(HttpServer.java:954)
        at
weblogic.servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1198)
        at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2549)
        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)
>
<Apr 23, 2003 1:03:09 PM PDT> <Error> <kernel> <000802> <ExecuteRequest failed
 java.lang.RuntimeException: Assertion botch: excessivly large digit 891908706
java.lang.RuntimeException: Assertion botch: excessivly large digit 891908706
        at java.lang.FloatingDecimal.dtoa(FloatingDecimal.java:760)
        at java.lang.FloatingDecimal.<init>(FloatingDecimal.java:500)
        at java.lang.Float.toString(Float.java:124)
        at java.lang.String.valueOf(String.java:2152)
        at java.lang.Float.toString(Float.java:278)
        at weblogic.servlet.logging.TimeLogField.logField(TimeLogField.java:37)
        at weblogic.servlet.logging.ELFLogger.log(ELFLogger.java:138)
        at weblogic.servlet.logging.LogManagerHttp.log(LogManagerHttp.java:324)
        at weblogic.servlet.internal.HttpServer.log(HttpServer.java:954)
        at
weblogic.servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1198)
        at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2549)
        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)
>
<Apr 23, 2003 1:03:09 PM PDT> <Error> <HTTP> <101214> <Included resource or
file &quot;/managed_content/webapp/components/dev2dev/docs/jmsfaq.html&quot; not found
from requested resource &quot;/docs/jmsfaq.jsp&quot;.>
<Apr 23, 2003 1:03:09 PM PDT> <Error> <kernel> <000802> <ExecuteRequest failed
 java.lang.RuntimeException: Assertion botch: excessivly large digit 20
java.lang.RuntimeException: Assertion botch: excessivly large digit 20
        at java.lang.FloatingDecimal.dtoa(FloatingDecimal.java:760)
        at java.lang.FloatingDecimal.<init>(FloatingDecimal.java:500)
        at java.lang.Float.toString(Float.java:124)
        at java.lang.String.valueOf(String.java:2152)
        at java.lang.Float.toString(Float.java:278)
        at weblogic.servlet.logging.TimeLogField.logField(TimeLogField.java:37)
        at weblogic.servlet.logging.ELFLogger.log(ELFLogger.java:138)
        at weblogic.servlet.logging.LogManagerHttp.log(LogManagerHttp.java:324)
        at weblogic.servlet.internal.HttpServer.log(HttpServer.java:954)
        at
weblogic.servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1198)
        at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2549)
        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)


The snippet of code that is producing the problem is

    long milsec = System.currentTimeMillis() -
         metrics.getInvokeTime();
       Float sec = new Float(milsec / 1000.0);

       try {
       buff.append(sec.toString());
     .......


now the really bizarre thing is that when we put a debug line
(system.out.println(&quot;The value is&quot; + value) ) in to see what the value actually
is the problem goes away.

Running with -Xint the problem goes from once a second to about 4-5 times per
day so this doesn't appear to be JIT specific.

Looks like it could be timing related.




 
Workaround  put in a debug statement.

currently this is being used
     try {
       buff.append(sec.toString());
}
catch (Exception e )
{
         System.out.println(&quot;An exception has occurred: &quot; + e );
         System.out.println(&quot;The milsec is: &quot; + milsec);
       System.out.println(&quot;The invoketime is: &quot; + metrics.getInvokeTime());
       System.out.println(&quot;Calling buf.append on the float value&quot;);

         }


 
Evaluation  A list of some failing floating-point values would help determine if the
problem is with the binary to decimal conversion library or elsewhere.

xxxxx@xxxxx 2003-06-26

 

[BoulderBum]

Upon further investigating, I found out that the trouble is with FloatingDecimal.java, a poorly documented class that may have a bug. I can't tell you how to fix the problem, but I can direct you to some people trying to figure out the problem.

http://forum.java.sun.com/thread.jsp?thread=412578&forum=31&message=1816191

Perhaps if you e-mail the author of the thread he may have solved the issue, but it sounds as if you may have to wait for Sun to work out a kink.