JDK-4881096 : Assertion botch: excessivly large digit 20 occurs every second on one box in clu
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.1_07
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: solaris_8
  • CPU: generic
  • Submitted: 2003-06-19
  • Updated: 2005-12-07
  • Resolved: 2005-12-07
Related Reports
Relates :  
JDK-4916788 - Double.toString generates "Assertion botch" RuntimeException
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 "/managed_content/webapp/components/dev2dev/docs/jmsfaq.html" not found from requested resource "/docs/jmsfaq.jsp".> 
<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("The value is" + 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.
Comments
EVALUATION ** Sep 30 2003 11:00AM Arunachalam,A ** Event: JWSSE is closing the escalation due to following reasons. o The fact that this problem happens in on of the four identical machines, suggests that this is more likely a hardware issue. o Also, in bugtraq, there were couple of bugs filed as the same issue which eventually culminated as a hardware issue. o JWSSE needs access to the machine which is causing this problem o If the Customer makes it a big issue, another escalation could be opened. But before opening another escalation, we should have the roadmap to work on it
07-12-2005
WORK AROUND put in a debug statement. currently this is being used try { buff.append(sec.toString()); } catch (Exception e ) { System.out.println("An exception has occurred: " + e ); System.out.println("The milsec is: " + milsec); System.out.println("The invoketime is: " + metrics.getInvokeTime()); System.out.println("Calling buf.append on the float value"); }
11-06-2004
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. ###@###.### 2003-06-26
26-06-2003