xxDark commented on PR #8277: URL: https://github.com/apache/netbeans/pull/8277#issuecomment-2682256863
After more digging, to answer your question @eirikbakke: I can't say for sure the cause of this. There are multiple factors: - Windows is closed source, so tracing the interaction between user mode and the kernel is difficult. I don't have enough knowledge to do this. Does `pfnWowEmptyClipBoard` post the related window message? Is it done in the kernel mode? - JDK on its own has issues with concurrent clipboard access, as was figured out - There is a lot of code without comments in AWT making investigation harder. For example, my current fix ensures that clipboard interactions from the troolkit thread are enqueued to EDT if there is one running. However, is this the correct fix? There is this comment https://github.com/openjdk/jdk/blob/cfeb7d6c964f63184c939f6f0625c6e7f1afdc31/src/java.desktop/windows/classes/sun/awt/windows/WClipboard.java#L67. While it talks about not calling the code on the toolkit thread, what if the opposite is also true and there are scenarios when some code should never be called on the EDT? There is no further elaboration on what "security holes" authors of this class talks about. - Further extending the second point, native code is also missing a lot of comments. Take the problematic `AwtClipboard::IsGettingOwnership` check (which I now think is probably the culprit). I don't have the time at this moment to do further diagnostics on this. From the sources: [/* This flag is set while we call EmptyClipboard to indicate to WM_DESTROYCLIPBOARD handler that we are not losing ownership */](https://github.com/openjdk/jdk/blob/cfeb7d6c964f63184c939f6f0625c6e7f1afdc31/src/java.desktop/windows/native/libawt/windows/awt_Clipboard.cpp#L40-L41) But why is this flag needed? If you follow along, you would assume, that if the window messages are processed on the toolkit thread, this seem to make no sense. The only point at which this flag is set to true is [here](https://github.com/openjdk/jdk/blob/cfeb7d6c964f63184c939f6f0625c6e7f1afdc31/src/java.desktop/windows/native/libawt/windows/awt_Clipboard.cpp#L144). Why? This method never blocks the caller thread and never waits for the `WM_DESTROYCLIPBOARD` to arrive. The `WM_DESTROYCLIPBOARD` arrives on the toolkit thread, but the caller can be any thread. So this is just a race condition and a check [here](https://github.com/openjdk/jdk/blob/cfeb7d6c964f63184c939f6f0625c6e7f1afdc31/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp#L1039) seem bogus to me. Thats why a lot of users probably see the bug manifest only after some time. But for me it happens immediately. I did further experiments yesterday, and noticed that if I just spam `CTRL+C` on a non-empty line, which apparently copies the current line, this is enough to trigger the bug if you quickly swap to the secondary window. One thing for certain is that there is a flaw at how JDK handles clipboard access IMO. Logic like [this](https://github.com/openjdk/jdk/blob/62f39bd6468d1c99bb0d6af6a96972bae96a7588/src/java.desktop/windows/classes/sun/awt/windows/WClipboard.java#L162) for example is equivalent to this: ```Java try { lock.lock(); .... } finally { lock.unlock(); } ``` What if `Lock::lock` throws? `finally` closure will just blindly unlock the lock if another thread is currently holding it? Absolutely, if there is no protection against that. According to ReactOS source code, [there is](https://github.com/mirror/reactos/blob/master/reactos/win32ss/user/ntuser/clipboard.c#L125) some protection in `CloseClipboard`. But I can't for sure that there is in Windows. Maybe the current logic is correct and intended to be this way. But this seems very wrong to me -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@netbeans.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@netbeans.apache.org For additional commands, e-mail: notifications-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
