/dto
Name: gm110360 Date: 09/03/2003


FULL PRODUCT VERSION :
Java version "1.4.1_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_03-b02)
Java HotSpot(TM) Client VM (build 1.4.1_03-b02, mixed mode)

FULL OS VERSION :
MS Windows 2000 (Version 5.00.2195)
Service pack 3

A DESCRIPTION OF THE PROBLEM :
We're seeing a stacktrace when running JDK 1.4.1:
  java.lang.RuntimeException: Assertion botch: excessivly large digit 611
    at java.lang.FloatingDecimal.dtoa(FloatingDecimal.java:762)
    [..]
I'll append the stacktrace in the "error" section below.

It appears to be a HotSpot bug, perhaps similar to your bug 4337050:
  http://developer.java.sun.com/developer/bugParade/bugs/4337050.html

This bug has been seen on multiple Win2K machines running:
   JDK 1.4.1_03
   JDK 1.4.1-rc-b19
It does *not* occur on these machines when we run using:
   JDK 1.4.0_03-b04
Also it doesn't appear to occur under Linux.

We haven't tried 1.4.2, due to porting issues to match recent JDK security API changes (e.g. the API change to "sun.security.x509.GeneralNames").

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The bug occurs late in our run and may be difficult to reproduce.

We tried catching the exception and logging the double's "rawBits", to see what the double value was. In one test we logged the bits as:
   405e3fedc0000000
which equates to this perfectly reasonable double value:
   120.99888610839844
A toy program to print this value on the above Win2K machine running 1.4.1 didn't reproduce the RuntimeException. Perhaps HotSpot needs to warm up, or this is a symptom of an unrelated HotSpot bug.

It'll be a bit difficult to package up our test for you to run, but we'll see what we can do if you need to run the test yourself. Let us know if you'd like us to run again with HotSpot debugging or special flags.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
FloatingDecimal should convert the bits into a String without throwing the RuntimeException.
ACTUAL -
See the stacktrace below...

ERROR MESSAGES/STACK TRACES THAT OCCUR :
here's a stacktrace:
-------------------------------------------------------------------------------
java.lang.RuntimeException: Assertion botch: excessivly large digit 120
    at java.lang..java
.dtoa(FloatingDecimal.java:762)
    at java.lang.FloatingDecimal.<init>(FloatingDecimal.java:442)
    at java.lang.Double.toString(Double.java:135)
    at java.lang.String.valueOf(String.java:2326)
    at java.lang.StringBuffer.append(StringBuffer.java:600)
    at org.cougaar.logistics.plugin.inventory.LogisticsInventoryFormatter.logAllocationResult(LogisticsInventoryFormatter.java:247)
    at org.cougaar.logistics.plugin.inventory.LogisticsInventoryFormatter.logAllocationResults(LogisticsInventoryFormatter.java:208)
    at org.cougaar.logistics.plugin.inventory.LogisticsInventoryFormatter.xmlLogNonProjectionARs(LogisticsInventoryFormatter.java:485)
    at org.cougaar.logistics.plugin.inventory.LogisticsInventoryFormatter.logResupplyToXMLOutput(LogisticsInventoryFormatter.java:838)
    at org.cougaar.logistics.plugin.inventory.LogisticsInventoryFormatter.logToXMLOutput(LogisticsInventoryFormatter.java:722)
    at org.cougaar.logistics.plugin.inventory.LogisticsInventoryFormatter.logToXMLOutput(LogisticsInventoryFormatter.java:747)
    at org.cougaar.logistics.plugin.inventory.LogisticsInventoryFormatter.logToXMLOutput(LogisticsInventoryFormatter.java:766)
    at org.cougaar.logistics.servlet.LogisticsInventoryServlet$InventoryGetter.getXMLFromLogPlan(LogisticsInventoryServlet.java:366)
    at org.cougaar.logistics.servlet.LogisticsInventoryServlet$InventoryGetter.execute(LogisticsInventoryServlet.java:322)
    at org.cougaar.logistics.servlet.LogisticsInventoryServlet.doPut(LogisticsInventoryServlet.java:107)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    at org.cougaar.lib.web.arch.leaf.LeafServlet.service(LeafServlet.java:113)
    at org.cougaar.lib.web.arch.root.RootServlet.service(RootServlet.java:180)
    at org.cougaar.lib.web.tomcat.HookServlet.service(HookServlet.java:79)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
    at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
    at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:190)
    at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:475)
    at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
    at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
    at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
    at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
    at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)22:56:49,921
    at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
    at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
    at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)22:56:49,921
    at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
    at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:368)
    at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
    at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
    at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
    at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
    at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1012)
    at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1107)
    at java.lang.Thread.run(Thread.java:536)


REPRODUCIBILITY :
This bug can be reproduced often.

---------- BEGIN SOURCE ----------
The trivial test does *not* reproduce the problem:
  public class Main {
    public static void main(String[] args) {
      System.out.print(120.99888610839844);
    }
  }

So far the only test case is our entire application.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
None; go back to using 1.4.0 instead of 1.4.1.
(Incident Review ID: 187015)
======================================================================