P1
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
testing.
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
NoGIFWithImage.class).
KL Group is looking into the problem from their end.
Attachment: ae4307467.zip
Contains:
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.
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
testing.
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
NoGIFWithImage.class).
KL Group is looking into the problem from their end.
Attachment: ae4307467.zip
Contains:
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.