Product: Aqua Data Studio
Version: 12.0.0-beta-36
Build #: 29263
Build Date: 2012-Sep-14 08:09:32 AM
Operating Environment: Linux (3.2.0-29-generic, amd64) / UTF-8 / en / US / Oracle Corporation 1.7.0_06-b24
Memory: Max=3,819,634,688; Total=741,801,984; Free=485,359,816; CPUs=8
Copy and paste 5000 lines doesnt work in any Editors for 12.0.0-beta-36 in Ubuntu 12.04
To reproduce
1. Open the attached world.sql in a text editor
2. Copy the entire contents
3. Open ADS 12.0.0-beta-36 and open a Query Window
4. Paste the lines of SQL code
Nothing happens
Compare it with ADS 11.0 - paste works in all editors without any problem
|
|
387 KB
The problem seems to be specific to Java 1.7.0_06 on Ubuntu 12.04.
On Ubuntu 12.04 with Java 1.7.0_06 in binary and development, we :
1. Run ADS and open a Text Editor
2. We run gedit and open a file with 5000 lines.
3. We copy from gedit all lines and try to paste in Text Editor. It does not paste nor give an error.
4. We copy from gedit 3650 line and we try to paste in Text Editor. It works. The limit seems to be ~3650.
5. We then open the file with 5000 lines and it opens ok.
6. We open another Text Editor and we copy from the 1st to the 2nd and it works.
7. We then copy from gedit to openoffice 4000 lines.
8. We then copy from open office 4000 lines and try to paste in ADS Text Editor and it fails.
Apply the above using Java 1.6.0_31 everything works correctly for the paste.
According to Tariq, the above also works with Java 1.7.0_06 on Windows. And with OSX using Java 1.6.0...
Indeed, this is a JVM 1.7.0_06 specific issue under Ubuntu. It fails while retrieving the content from clipboard. Here is the stacktrace:
java.io.IOException: Owner failed to convert data"
sun.awt.X11.XSelection.validateDataGetter(XSelection.java:444)
sun.awt.X11.XSelection.getData(XSelection.java:378)
sun.awt.X11.XClipboard.getClipboardData(XClipboard.java:120)
sun.awt.datatransfer.ClipboardTransferable.fetchOneFlavor(ClipboardTransferable.java:118)
sun.awt.datatransfer.ClipboardTransferable.<init>(ClipboardTransferable.java:97)
sun.awt.X11.XClipboard.getContents(XClipboard.java:106)
javax.swing.TransferHandler$TransferAction.actionPerformedImpl(TransferHandler.java:1747)
javax.swing.TransferHandler$TransferAction.access$700(TransferHandler.java:1684)
javax.swing.TransferHandler$TransferAction$1.run(TransferHandler.java:1707)
javax.swing.TransferHandler$TransferAction$1.run(TransferHandler.java:1705)
java.security.AccessController.doPrivileged(AccessController.java)
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
javax.swing.TransferHandler$TransferAction$2.run(TransferHandler.java:1722)
javax.swing.TransferHandler$TransferAction$2.run(TransferHandler.java:1720)
java.security.AccessController.doPrivileged(AccessController.java)
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
javax.swing.TransferHandler$TransferAction.actionPerformed(TransferHandler.java:1719)
javax.swing.text.JTextComponent.invokeAction(JTextComponent.java:1513)
javax.swing.text.JTextComponent.paste(JTextComponent.java:1491)
it seems that the WindowPropertyGetter is prematurely disposed and thus the exception is thrown.
Indeed, this is a JVM 1.7.0_06 specific issue under Ubuntu. It fails while retrieving the content from clipboard. Here is the stacktrace:
java.io.IOException: Owner failed to convert data"
sun.awt.X11.XSelection.validateDataGetter(XSelection.java:444)
sun.awt.X11.XSelection.getData(XSelection.java:378)
sun.awt.X11.XClipboard.getClipboardData(XClipboard.java:120)
sun.awt.datatransfer.ClipboardTransferable.fetchOneFlavor(ClipboardTransferable.java:118)
sun.awt.datatransfer.ClipboardTransferable.<init>(ClipboardTransferable.java:97)
sun.awt.X11.XClipboard.getContents(XClipboard.java:106)
javax.swing.TransferHandler$TransferAction.actionPerformedImpl(TransferHandler.java:1747)
javax.swing.TransferHandler$TransferAction.access$700(TransferHandler.java:1684)
javax.swing.TransferHandler$TransferAction$1.run(TransferHandler.java:1707)
javax.swing.TransferHandler$TransferAction$1.run(TransferHandler.java:1705)
java.security.AccessController.doPrivileged(AccessController.java)
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
javax.swing.TransferHandler$TransferAction$2.run(TransferHandler.java:1722)
javax.swing.TransferHandler$TransferAction$2.run(TransferHandler.java:1720)
java.security.AccessController.doPrivileged(AccessController.java)
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
javax.swing.TransferHandler$TransferAction.actionPerformed(TransferHandler.java:1719)
javax.swing.text.JTextComponent.invokeAction(JTextComponent.java:1513)
javax.swing.text.JTextComponent.paste(JTextComponent.java:1491)
it seems that the WindowPropertyGetter is prematurely disposed and thus the exception is thrown.
Unfortunately, there is a typo in the Java 7 source code (see line below highlighted in red, it should be validateDataGetter(incrDataGetter); ):
public byte[] getData(long format, long time) throws IOException {
...
// Handle incremental transfer.
if (dataGetter.getActualType() ==
XDataTransferer.INCR_ATOM.getAtom()) {
...
dataGetter.dispose();
ByteArrayOutputStream dataStream = new ByteArrayOutputStream(len);
while (true) {
WindowPropertyGetter incrDataGetter =
new WindowPropertyGetter(XWindow.getXAWTRootWindow().getWindow(),
selectionPropertyAtom,
0, MAX_LENGTH, false,
XConstants.AnyPropertyType);
try {
XToolkit.awtLock();
XToolkit.addEventDispatcher(XWindow.getXAWTRootWindow().getWindow(),
incrementalTransferHandler);
propertyGetter = incrDataGetter;
try {
XlibWrapper.XDeleteProperty(XToolkit.getDisplay(),
XWindow.getXAWTRootWindow().getWindow(),
selectionPropertyAtom.getAtom());
// If the owner doesn't respond within the
// SELECTION_TIMEOUT, we terminate incremental
// transfer.
waitForSelectionNotify(incrDataGetter);
} catch (InterruptedException ie) {
break;
} finally {
propertyGetter = null;
XToolkit.removeEventDispatcher(XWindow.getXAWTRootWindow().getWindow(),
incrementalTransferHandler);
XToolkit.awtUnlock();
}
validateDataGetter(dataGetter);
if (incrDataGetter.getActualFormat() != 8) {
throw new IOException("Unsupported data format: " +
incrDataGetter.getActualFormat());
}
count = incrDataGetter.getNumberOfItems();
if (count == 0) {
break;
}
if (count > 0) {
ptr = incrDataGetter.getData();
for (int index = 0; index < count; index++) {
dataStream.write(Native.getByte(ptr + index));
}
}
data = dataStream.toByteArray();
} finally {
incrDataGetter.dispose();
}
}
}
...
}
The validateDataGetter() method throws an IOException("Owner failed to convert data") if the WindowPropertyGetter instance received as parameter has been disposed (and it actually has, see the line above highlighted in green).
The snippet code shown above indicates that the validation inside the while loop should actually be performed on the incrDataGetter variable, which is updated on each step inside the while loop. It is probably a typo.
The copy-paste operation works (under Java 1.7.0_06) for smaller blocks of text because the transfer is not incrementally performed and thus the erroneous code snippet (shown above) is not reached.
This issue needs to be fixed on the Java 7 upstream.
Unfortunately, there is a typo in the Java 7 source code (see line below highlighted in red, it should be validateDataGetter(incrDataGetter); ):
public byte[] getData(long format, long time) throws IOException {
...
// Handle incremental transfer.
if (dataGetter.getActualType() ==
XDataTransferer.INCR_ATOM.getAtom()) {
...
dataGetter.dispose();
ByteArrayOutputStream dataStream = new ByteArrayOutputStream(len);
while (true) {
WindowPropertyGetter incrDataGetter =
new WindowPropertyGetter(XWindow.getXAWTRootWindow().getWindow(),
selectionPropertyAtom,
0, MAX_LENGTH, false,
XConstants.AnyPropertyType);
try {
XToolkit.awtLock();
XToolkit.addEventDispatcher(XWindow.getXAWTRootWindow().getWindow(),
incrementalTransferHandler);
propertyGetter = incrDataGetter;
try {
XlibWrapper.XDeleteProperty(XToolkit.getDisplay(),
XWindow.getXAWTRootWindow().getWindow(),
selectionPropertyAtom.getAtom());
// If the owner doesn't respond within the
// SELECTION_TIMEOUT, we terminate incremental
// transfer.
waitForSelectionNotify(incrDataGetter);
} catch (InterruptedException ie) {
break;
} finally {
propertyGetter = null;
XToolkit.removeEventDispatcher(XWindow.getXAWTRootWindow().getWindow(),
incrementalTransferHandler);
XToolkit.awtUnlock();
}
validateDataGetter(dataGetter);
if (incrDataGetter.getActualFormat() != 8) {
throw new IOException("Unsupported data format: " +
incrDataGetter.getActualFormat());
}
count = incrDataGetter.getNumberOfItems();
if (count == 0) {
break;
}
if (count > 0) {
ptr = incrDataGetter.getData();
for (int index = 0; index < count; index++) {
dataStream.write(Native.getByte(ptr + index));
}
}
data = dataStream.toByteArray();
} finally {
incrDataGetter.dispose();
}
}
}
...
}
The validateDataGetter() method throws an IOException("Owner failed to convert data") if the WindowPropertyGetter instance received as parameter has been disposed (and it actually has, see the line above highlighted in green).
The snippet code shown above indicates that the validation inside the while loop should actually be performed on the incrDataGetter variable, which is updated on each step inside the while loop. It is probably a typo.
The copy-paste operation works (under Java 1.7.0_06) for smaller blocks of text because the transfer is not incrementally performed and thus the erroneous code snippet (shown above) is not reached.
This issue needs to be fixed on the Java 7 upstream.
The code snippets above are from OpenJDK 7, but I guess Oracle's JDK source code version (not public) for the XSelection class is similar.
After some diggings on the net, I've found few references with the same exception, but no solution.
http://netbeans.org/bugzilla/show_bug.cgi?id=157652
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6936006
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6180249
The code snippets above are from OpenJDK 7, but I guess Oracle's JDK source code version (not public) for the XSelection class is similar.
After some diggings on the net, I've found few references with the same exception, but no solution.
http://netbeans.org/bugzilla/show_bug.cgi?id=157652
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6936006
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6180249
And here is the changeset that introduced the typo: http://hg.openjdk.java.net/jdk7/jdk7-gate/jdk/rev/6fd2d28e66cd . This was a fix for Java issue #6340263 ( ensure that .isDisposed() is called prior to .isExecuted() ) but, as you can see, the code refactoring went wrong ( incrDataGetter replaced with dataGetter ).
OpenJDK 1.6.0_24 source-code doesn't include this code refactoring and that's why Paste action works as expected, no matter if data is retrieved incrementally or not from the clipboard.
And here is the changeset that introduced the typo: http://hg.openjdk.java.net/jdk7/jdk7-gate/jdk/rev/6fd2d28e66cd . This was a fix for Java issue #6340263 ( ensure that .isDisposed() is called prior to .isExecuted() ) but, as you can see, the code refactoring went wrong ( incrDataGetter replaced with dataGetter ).
OpenJDK 1.6.0_24 source-code doesn't include this code refactoring and that's why Paste action works as expected, no matter if data is retrieved incrementally or not from the clipboard.
Reported this problem to the awt-dev@openjdk.java.net mailing list and also posted a new issue on http://bugs.sun.com . Probably they'll fix this typo on a next JRE release.
Reported this problem to the awt-dev@openjdk.java.net mailing list and also posted a new issue on http://bugs.sun.com . Probably they'll fix this typo on a next JRE release.
Here is the reported upstream issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7199196
Here is the reported upstream issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7199196
This is not fixed in the latest JRE release. I can see that the issue logged is still not updated.
Able to reproduce in Ubuntu 64 bit 12.04 with latest JRE 1.7.0_25-b15 and ADS 13.0.2-4 Build.
This is not fixed in the latest JRE release. I can see that the issue logged is still not updated.
Able to reproduce in Ubuntu 64 bit 12.04 with latest JRE 1.7.0_25-b15 and ADS 13.0.2-4 Build.
It seems they've targeted my issue (that I've reported on bugs.sun.com) for JRE 8, so probably they won't fix it on a JRE 1.7.x release.
It seems they've targeted my issue (that I've reported on bugs.sun.com) for JRE 8, so probably they won't fix it on a JRE 1.7.x release.
@nilesh - can you verify if this is fixed in ADS v17 and close this issue ?
@nilesh - can you verify if this is fixed in ADS v17 and close this issue ?
Working fine for OS-Ubuntu-14.04 in ADS17.0.0-Alpha-19.
Working fine for OS-Ubuntu-14.04 in ADS17.0.0-Alpha-19.
This issue is now fixed in ADS v17 with java 1.8
This issue is now fixed in ADS v17 with java 1.8
Issue #7588 |
| Closed |
| Fixed |
| Resolved |
Completion |
| No due date |
| No fixed build |
| No time estimate |
The problem seems to be specific to Java 1.7.0_06 on Ubuntu 12.04.
On Ubuntu 12.04 with Java 1.7.0_06 in binary and development, we :
1. Run ADS and open a Text Editor
2. We run gedit and open a file with 5000 lines.
3. We copy from gedit all lines and try to paste in Text Editor. It does not paste nor give an error.
4. We copy from gedit 3650 line and we try to paste in Text Editor. It works. The limit seems to be ~3650.
5. We then open the file with 5000 lines and it opens ok.
6. We open another Text Editor and we copy from the 1st to the 2nd and it works.
7. We then copy from gedit to openoffice 4000 lines.
8. We then copy from open office 4000 lines and try to paste in ADS Text Editor and it fails.
Apply the above using Java 1.6.0_31 everything works correctly for the paste.
According to Tariq, the above also works with Java 1.7.0_06 on Windows. And with OSX using Java 1.6.0...