On Wed, 5 Aug 2026 15:05:20 GMT, Matthias Baesken <[email protected]> wrote:
>> GlobalLock has a return value that indicates errors; this should be handled. >> >> While looking into this, in Java_sun_awt_windows_WPrinterJob_deviceStartPage >> a free call was found that is not placed correctly and can lead to leaks. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > awt_ClipBoard handle failing GlobalLock differently In` Java_sun_awt_windows_WClipboard_publishClipboardData` ( awt_Clipboard.cpp ) we have some GlobalAlloc calls but I am not completely sure were the freeing (GlobalFree) happens. Or is it not done intentionally ? https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setclipboarddata says that the memory must be kept until CloseClipboard is called `If SetClipboardData succeeds, the system owns the object identified by the hMem parameter. The application may not write to or free the data once ownership has been transferred to the system, but it can lock and read from the data until the [CloseClipboard](https://learn.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-closeclipboard) function is called. (The memory must be unlocked before the Clipboard is closed.)` ------------- PR Comment: https://git.openjdk.org/jdk/pull/32206#issuecomment-5193707030
