On Sun, 13 Apr 2025 16:13:43 GMT, Matthias Bläsing <mblaes...@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
