Community
Participate
Working Groups
Whenever I start a new instance of eclipse a bunch of window message handles are registered for facilitating drag and drop. This is done through the RegisterWindowMessage windows API, and the problem is that according to the windows MSDN documentation these message handles can never be released. Although this is a structural leak in windows it is usually no problem, because the number of different drag-and-drop message types is limited. However, some eclipse UI components add the current time stamp (System.currentTimeMillis()) to the message type, so each instance of eclipse gets a unique ID which never gets released. This is a significant problem for us, because we use eclipse in a regression test environment, and in about 10 days the window message registry overflows and we need to reboot the machine. The problematic window message registration calls are triggered through calls to Transfer.registerType(... something with timestamp...), and the occasions I could find were: EditorInputTransfer, LocalSelectionTransfer, MarkerTransfer and ResourceTransfer. Regards, Olaf
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
The problem is still occurring (I checked 4.6 and 4.9), and it would be really great if this could be fixed. Just to provide a little more context, here's a snippet of code that triggers the registration in org.eclipse.jface.util.LocalSelectionTransfer: // First attempt to create a UUID for the type name to make sure that // different Eclipse applications use different "types" of // <code>LocalSelectionTransfer</code> private static final String TYPE_NAME = "local-selection-transfer-format" + Long.valueOf(System.currentTimeMillis()).toString(); //$NON-NLS-1$; private static final int TYPEID = registerType(TYPE_NAME); So it's clear that appending the timestamp was intentional, but unfortunately this leaks Windows resources so I think it must be done in a different way.
Reopened, see Comment 2
(In reply to Olaf Scheufen from comment #3) > Reopened, see Comment 2 Olaf could you provide a fix for the problem?
Sorry, I can't fix this.
