-
Notifications
You must be signed in to change notification settings - Fork 549
8269630: Bad clipboard data causes JVM to crash #1999
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
👋 Welcome back lkostyra! A progress list of the required criteria for merging this PR into |
|
❗ This change is not yet ready to be integrated. |
|
Can you turn the test case from the bug report into an automated test? /reviewers 2 |
|
@kevinrushforth |
I was not sure about this, mostly because of difference in behavior between platforms. For now I could add a test that simply sets I can also write a proper test, make it work only on Linux assuming this is the behavior we want to follow and exclude it on other platforms, that way JDK-8373090 will have it mostly ready to go. Which option do you prefer? |
|
Questions:
Another consideration is what should happen when a single item of unacceptable data is put into the clipboard. Should it replace the existing clipboard content (possibly from another application), or should it be a no-op? |
This commit fixes the JVM crash caused by bad Clipboard data on Linux.
On Windows the Clipboard is a bit more generic in how it operates - even if the MIME type mismatches, the Clipboard will accept any object and then return it. GTK is less generic in this regard (at least our Glass implementation) so for cases like text it requires us to fetch the String contents and set those directly onto the Clipboard.
Moreover,
ClipboardContentis simply an extension ofHashMapwhich exposesput()and lets us assign whatever object we want to whatever MIME type we want. As such, if we follow the example code from the JDK issue, we would try to fetch String contents from something that is not a String, causing SIGSEGV.Fix was done by type-checking incoming
ClipboardContentdata. I saw that this can also happen in other content types than text, so I guarded those as well. If types are not what we expect them to be, the attempt to update the System Clipboard is silently discarded and the crash is avoided. According to my manual testing, as long as data types are correct everything seems to work fine.As a side-note, this also shows there is discrepancy in how
Clipboardoperates between platforms. We should unify that behavior, but that is a larger task which will be solved under JDK-8373090.Progress
Issue
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1999/head:pull/1999$ git checkout pull/1999Update a local copy of the PR:
$ git checkout pull/1999$ git pull https://git.openjdk.org/jfx.git pull/1999/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 1999View PR using the GUI difftool:
$ git pr show -t 1999Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1999.diff
Using Webrev
Link to Webrev Comment