The leak occurs with all 1.3.x and 1.4.x JVMs on Solaris and Linux.
The leak does not seem to occur with Java 1.1.8 on Solaris, Linux or Windows.
The leak does not seem to occur with 1.3.1 on Windows 2000.

From Incident Manager report #135628 : -

% java -version
java version "1.4.0-beta3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b84)
Java HotSpot(TM) Client VM (build 1.4.0-beta3-b84, mixed mode)

Memory leak when getting the clipboard contents.

Our program has to do this repeatedly, and this bug will cause our application
to eat up all available memory and ultimately crash with an OutOfMemory error.

Repro as follows:

This bug occurs on both Solaris and Linux (Debian "testing" and RedHat 7.1) with
JDK 1.4b3.

1. Compile and run MemoryTest.java program (below) in a dtterm window.
2. Run `top' in another dtterm window and press `M' to sort by process size.
   Alternatively, you can check memory usage with `ps -eyl | grep Memory' on
   Solaris.
3. Select a screenful of text in another dtterm window. To get a good chunk of
   data I ran `less /bin/ls', selected a screen-full of data with the mouse and
   copied to the clipboard using dtterm's menu.

The size of the MemoryTest process grows and grows until the machine pages and
swaps to the point of being unusable.

Note, the problem only occurs when data is placed on the X CLIPBOARD selection.

Since dtterm users clipboard, making a selection in dtterm will trigger the
bug. Netscape can also be used if you press Ctrl-C to copy data to the
CLIPBOARD. Note you won't see the problem if you use the X PRIMARY selection,
for example, when running with xterm. If you want to repro the problem with
xterm, you can add the following X resources prior to running xterm:

~Ctrl ~Meta <Btn2Up>: insert-selection(PRIMARY,CLIPBOARD,CUT_BUFFER0)\n<BtnUp>: select-end(PRIMARY,CLIPBOARD,CUT_BUFFER0)\n



MemoryTest.java
----------------
import java.awt.Toolkit;
import java.awt.datatransfer.Clipboard;

public class MemoryTest {


   public static void main(String[] args) {
   Clipboard systemClipboard = Toolkit.getDefaultToolkit().getSystemClipboard();
        Object requestor = new Object();
        int count = 0;
        while (true) {
          systemClipboard.getContents(requestor);
// if (++count == 500) {
// System.out.println("sleeping");
// try { Thread.sleep(1 * 1000); } catch (InterruptedException ie) { }
// Runtime.getRuntime().gc();
// count = 0;
// }
        }
    }
}



###@###.### - 11/26/01 :

Based on my testing, there is a memory leak in this program even if you don't do any copy to the clpiboard. If you run the program in one window and monitor the memory using ps -el command, you will see the value in SZ column increasing continously. It never decreases. if you copy a screenful of data from dtterm to the Clipboard then the process memory growth is much more rapid. That is, it appears the size of the leak is related to the amount of data on the CLIPBOARD.
Uncommenting the lines in the above code did n't help. I even tried
 
x = systemClipboard.getContents(requestor);
x = null;
 
to see if it will force garbage collection, but did n't make any difference.
I think the leak is clearly triggered by getting the clipboard contents.
Since this happens only on Unix platforms and was working fine with earlier releases of Java, I therefore suspect the leak is somewhere in the guts of the native X Windows clipboard handling code, introduced in the Java 2 platform.