RFR: 8353950: Clipboard interaction on Windows is unstable

[ExE Boss]

On Sun, 13 Apr 2025 16:13:43 GMT, Matthias Bläsing <mblaesing at openjdk.org> wrote:

>> - Introduce a lock into WClipboard that protects the code between
>>   openClipboard/closeClipboard invocations.
>>   The native side does not allow to open the clipboard multiple
>>   times or share the opened clipboard between multiple threads.
>> 
>> - Remove of need to call openClipboard/closeClipboard from
>>   getClipboardFormats by using the win32 call
>>   GetUpdatedClipboardFormats
>> 
>> - Prevent a race-condition by not registering the connection
>>   between java and native side of clipboard multiple time, but
>>   just at construction time.
>
> Some further comments:
> 
> - More information than provided in the PR summary can be found in the two commits, which represent the steps I took to to fix this.
> - From my testing this change also fixes JDK-8332271
> - Testing:
>   - fastdebug build does not hit asserts anymore for the reproducer code (See e893b368a0e32ff17c1182fb261e0561d48827d3 / issue report)
>   - reproducer code for JDK-8332271 does not crash anymore. Code was run for multiple minutes and no crash was observed
>   - tests from test/jdk/java/awt/Clipboard were run and tests succeeded in release and fastdebug configuration

@matthiasblaesing
You need to put the following in a comment or at the end of the PR body to mark **[JDK‑8332271]** as fixed by this PR[^1]:



[JDK‑8332271]: https://bugs.openjdk.org/browse/JDK-8332271 "[JDK‑8332271] Reading data from the clipboard from multiple threads crashes the JVM"

[^1]: https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-%2Fissue

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24614#issuecomment-2813032159