Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4301596

JDK1.2.2 - Java application on quad cpu NT machine-fatal memory access violation



    • 005
    • x86
    • windows_nt


      We run a production web server and use KL Group's JClass Chart. Since that produ
      ct is Swing based only 1 chart can be produced at a time in a given virtual mach
      ine. We normally run with multiple VMs available to service our chart requests.
       While running stress tests on Windows NT we encounter fatal memory access viola
      tions. Additionally we noticed that there is a memory leak associated with the

      We boiled our test down to a very small Java client of JClass Chart. It still re
      quires the JClass Chart JAR file to run.

      To reproduce the problem we run on a quad processor, and launch 4 Java programs,
       each launched from its own command prompt in NT 4 service pack 5, each running
      our test program Leak. To start we run
              java Leak 1000
      Where 1000 is the number of iterations to run. With a quad processor it fails fa
      irly quickly.

      We have reproduced the problem with 1.2.2 and with 1.3. In 1.3 it fails with bot
      h the default settings and with -classic.

      The problem also occurs in 1.3 on a quad processor with the default settings whe
      n running a single VM with the command line:
      java Leak 5000.

      Source code is Leak.java. It was compiled under 1.2.2 JDK.
      The KL Groups jar file is jcchart401k.jar.
      The KL Group jar file is produced by [to be made available later].

      Other details
      Problem is repeatable on quad processor Compaq Proliant 7000, 785, 825 KB ram, b
      uild NT 4.00.1381, service pack 5. The problem does not occur on a single proces
      sor. It is not known if it occurs on a dual processor.

      The Leak.java also exhibits a memory leak. KL group is aware of some necessary f
      ixes to their code. KL Group also wants us to alter our code to null out a field
      . We'll get to that shortly. Note that this field is reassigned new objects agai
      n and again so its not clear why it would cause a significant memory leak.

      KL Group insisted on the removal of Dr. Watson. We did this but there was no cha
      nge in the application.
      KL Group believed that the GIF encoding was at fault. We removed the GIF encodin
      g (see LeakNoGIFWithImage.zip) and it still failed. We took the additional step
      of removing the image creation as well (see LeakNoGIF.zip) and it worked. So it
      looks like the image creation is suspect. (The simplest thing that fails is Leak

      KL Group is looking into the problem from their end.

      Attachment: ae4307467.zip
      Leak.java - Java application reproduce the problem
      jcchart401k.jar - third party jar file needed to build application

      *** rkarpe 02/08/00 ***
      Second attachment bugInfo.zip.Z contains error message from JavaVM,
      along with Dr. Watson dumps on a 4-CPU development system along with
      similar info from a 2-CPU production system.




            hongzh Hong Zhang
            rletteri Robert Letteri (Inactive)
            0 Vote for this issue
            0 Start watching this issue