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

Large memory leaks in zip.dll using JNI

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P2
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.4.1_05
    • Fix Version/s: None
    • Component/s: core-libs

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                martin Martin Buchholz
                Reporter:
                duke J. Duke (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: