JDK-6407026 : Memory leak using OleInitialize()/OleUninitialize() in SWT
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0u22,6,6u18
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp,windows_7
  • CPU: x86
  • Submitted: 2006-03-31
  • Updated: 2013-09-12
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b03Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Description
From https://bugs.eclipse.org/bugs/show_bug.cgi?id=127374 :

I believe that JFieldText uses
OLE somehow (Drag&Drop or clipboard) and relies on paired calls to
OleInitialize()/OleUninitialize() to free up memory, but because of the extra
calls made by the testcase, the OLE ref count does not go down to zero and
memory is leaked. Please could you take a look at this?

import java.awt.*;

import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JTextField;

import org.eclipse.swt.internal.win32.*;
//import org.eclipse.swt.widgets.Display;

/**
 * @author scheglov_ke
 */
public class PR127374 {
        /**
         * @param args
         */
        public static void main(String[] args) throws Exception {
                //Display display = new Display();
                        OS.OleInitialize(0);
                //
                for (int i = 0; i < 100; i++) {
                    System.out.println(i);
                    JFrame frame = new JFrame();
                    //
                    JTextField textField = new JTextField();
                    frame.getContentPane().add(textField, BorderLayout.NORTH);
                    //
                    JLabel label = new JLabel(getBigString());
                    frame.getContentPane().add(label, BorderLayout.SOUTH);
                    //
                    frame.setVisible(true);
                    frame.setVisible(false);
                    //frame.getContentPane().remove(textField); //un-comment
this line to remove leak
                    frame.dispose();
                    //
                    PR127374.printMemory();
                }
                OS.OleUninitialize();
                //display.dispose();
                //
                Thread.sleep(100000);
        }
        private static void printMemory() {
                System.gc();
                System.out.println(Runtime.getRuntime().totalMemory() -
Runtime.getRuntime().freeMemory());
        }
        private static String getBigString() {
                int size = 1024 * 1024;
                StringBuffer sb = new StringBuffer(size);
                for (int i = 0; i < size; i++) {
                        sb.append('*');
                }
                return sb.toString();
        }
}

Comments
SUGGESTED FIX http://javaweb.sfbay/jcg/1.7.0-dolphin/awt/6407026/ *** (#1 of 1): [ UNSAVED ] ###@###.###
13-10-2006

EVALUATION The suggestion is correct. The function ::CoLockObjectExternal is calling from wrong tread. In absence of OLE initialization both calls of ::CoLockObjectExternal do nothing, but in presence of active OLE the first call ::CoLockObjectExternal locks IDropTarget interface by AddRef before the first marshaling in wrong thread, but the second CoLockObjectExternal call cannot unlock IDropTarget interface because it is already bound by marshaling with another (AWT Toolkit) thread. The ::CoLockObjectExternal function is actual just for interfaces produced by IClassFactory and in VERY SPECIFIC cases. It isn't such a case and both calls of ::CoLockObjectExternal have to be removed from code. It fixes the problem.
26-09-2006

EVALUATION I suspect that this is a duplicate of 6411042 (AWT Memory Leak) And the caus eof the problem is that we violate rules of single-threaded apartment
11-05-2006

EVALUATION Swing installs an (AWT, OLE-based) DropTarget on JTextFileds. Should investigate whether we can free more memory on disposal of a frame with associated DropTargets.
31-03-2006