We experience a large memory leaks from a variety of places, including zip.dll, fontmanager.dll and awt.dll, which starts with a base memory leak every time we run the JVM (1.4.1_05) and then grows with every RTF file we upload. We have been using Compuware Boundschecker as our memory tracking tool for this project.

Attached a test case( testcase.zip) to this bug report. Most of the leaks are shown with zip.dll with this test case. We have checked with 1.4.1_05 on Wndows200.

We have test setup with Vc++6.0 and Boundchecker with 1.4.1_05. We confirmed that leaks are seen with test code after exiting the code.

Here is what happens in code.
 It is an MFC-based program that calls(3_4v4.exe) our JNI code which is contained in these two files:

      LogArteportalInterface - the mediator between C++ calls and the Java
Object JTsJNITranslationInterface.java (which is contained in Logging.jar)
      LogJVMInterface - this is the JVM/JNI initialization code....we
used the Java.exe launcher code available with the Java SDK as our model.

The main action happens inside the ChildView OnPaint() method. All I simply
do here is call a method that uses JNI to call a Java method from the above
mentioned class. The Java class simply returns the value "true", nothing
more. Which is true of the line of code

BOOL val = intf.ConnectPrimary( );

in this method. So, val will always be TRUE. There are other calls to the JNI class in the CChildView constructor. The Initialise method calls
constructs the Java object that we are using....note that there is only one Java Object that is being called across the JNI.

So, this code makes some calls across the JNI and gets the value TRUE back and then prints it to a window. That's all. And with that, I get 700KB+ of
leaks.

We suspect this is a jvm issue as the leak is seen in zip.dll, with test case and at customer loacation similar leaks were observed in fontmanager.dll and awt.dll.