JDK-4513976 : DnDImageTest failing for between JVM scenario on Solaris 64-bit
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2001-10-12
  • Updated: 2002-03-25
  • Resolved: 2002-03-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.1 hopperFixed
Related Reports
Relates :  
JDK-4397407 - Unix (X11): Memory leak in image transfer code
Relates :  
JDK-4655996 - JCK1.4: api/javax_swing/JPasswordField/descriptions.html#setgetXXX fails
Relates :  
JDK-4818143 - NetBeans Hungs on sun.awt.datatransfer.ClipboardTransferable.getClipboardData
Relates :  
JDK-4648733 - HTMLTransferConsoleOutputTest and GetContentsInterruptedTest occasionally fail
Description
The DnDMerlinQLTestsuite DnDImageTest is failing for between JVM scenario on Solaris 64-bit only (Ultra 10).  This has been observed on Solaris 8 and Solaris 9.  The test passes on 32-bit versions of Solaris 2.6 and 7 (as well as other platforms).

Each test in the DnDMerlinQLTestsuite has two scenarios:
- Within Same JVM
- Between JVM

The DnDImageTest will pass in SameJVM mode but fail in BetweenJVM mode with core exception:

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0xFDFB4844
Function=Java_sun_awt_datatransfer_DataTransferer_platformImageBytesToImageData+0x2C8
Library=/net/jdk.sfbay/export/disk6/promoted/jdk/1.4/beta3/b83/binaries/solsparc/jre/lib/sparc/motif21/libmawt.so
...
...

The complete log is attached as file "hs_err_pid8631.log".

For both test scenarios, the DataFlavor used is:
"image/x-java-Image; class=java.awt.Image"

The failure may have been present for a few builds as it was thought to be related to DnD performance degradation bug (the test suite would generate some false failures because extra time was required for drop to complete).

Steps to reproduce
------------------
The DnDMerlinQLTestsuite is located in the workspace:
/net/sqesvr/export/dnd/Merlin_dnd_ws/DnDMerlinQLTestsuite

1) Copy the test suite to a local directory and change all permissions to allow write access.

2) The tests for the suite are located in the directory:
DnDMerlinQLTestsuite/src/testcases/

Remove all other test cases from the directory except for DnDImageTest.java

3) Go to the root test directory:
DnDMerlinQLTestsuite/

4) set JAVA_HOME variable.

5) type  "gnumake"

6) The test suite will compile all classes and execute any tests in the testcases/ directory (in this case only DnDImageTest.java).

7) Observe the failure in the second part of the test
	- first part (sameJVM) of the test will pass
	- second part (betweenJVM) of the test will fail

 Other information
-------------------
- Bug was still occurring with Merlin build 1.4.0-beta3-b83
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper FIXED IN: hopper INTEGRATED IN: hopper VERIFIED IN: hopper
17-09-2004
SUGGESTED FIX Name: dsR10078 Date: 02/12/2002 The suggested fix is to use PNG format as the target atom for Image transfer. Though it is not registered with the X11 registry yet, it is widely adopted as an image transfer format. To implement image transfer based on PNG we can use Image I/O facilities. In the future we should try to rearchitect all image transfer to use Image I/O. With this approach the native image translation code is not needed anymore and should be removed. Also the code related to the selectionRequestorWindow should be removed as it was used only for the old image translation model. The suggested fix resolves existing problems with image transfer: * bug 4397407, as we won't create pixmaps for image transfer anymore; * image transfer problems existsing as of JDK1.4.0rc-b92 related to the client endiannes: * images cannot be transferred between clients with different endianness (data translation failure is reported); * image transfer between two little-endian clients causes messes up colors. The fix for the data transfer failure caused by the selection owner timed out: 1.Xt imposes a limitation on the owner response time to guarantee that the requestor doesn't hang if the selection owner hangs. We assume that for Java it is more appropriate to guarantee that the selection transfer succeeds if the selection owner doesn't hang, so we set a limitation to the maximum possible value. 2.If the transfer failure is reported to the data requestor, we determine what kind of transfer failure happened: * selection owner timed out; * selection owner failed to convert the selection data; * other failure; and throw an IOException with an appropriate message. 3.Currently the data transfer system is designed so that IOExceptions occured during the clipboard data transfer in a particular native format are stored instead of the transfer data for this format and thrown to the client code when the data in that format is requested. However this is not implemented properly: the contents for each format is casted to a byte array which causes ClassCastException. 4.Currently we use XT_CONVERT_FAIL type to report data conversion failure on the selection owner side. According to the Xt reference manual this type is only intended to be used by Xt to report that selection owner does not respond within the timeout interval. The type None is more appropriate here. ###@###.### 2002-02-12 ======================================================================
12-02-2002
EVALUATION Name: biR10147 Date: 11/14/2001 This bug is reproducible on Ultra SPARC Creator 3D (both 10 and 60) with additional video card installed (both in 32-bit and 64-bit modes). It happens because in that case we use different visuals in native image transfer while creating and getting the image. Thus, reading the image using a visual different from one causes us to interpret pixel's color incorrectly leading to a crash. ###@###.### ====================================================================== Name: dsR10078 Date: 02/12/2002 With the original design of image transfer, PIXMAP was chosen as a native transfer format on X11 systems. The reason was that it is the only appropriate target atom registered with the X11 registry and specified by the ICCCM. To transfer images with this format, the selection owner should create an X pixmap based on the image data, transfer the pixmap id to the selection requestor and the requestor should extract the image data from the X pixmap. However, it turned out that image transfer implementation based on PIXMAP format has three major deficiencies: 1.Image transfer capabilities are limited by the X server capabilities. So that if the X server supports maximum 8 bits-per-pixel, Java applications will not be able to perform loseless transfer of images with more than 8 bits-per-pixel. 2.Image transfer introduces a resource leak (4397407). Pixmaps are precious server resources and should be freed as soon as possible. The selection owner that provides a pixmap id as the transfer data is considered the owner of this pixmap, i.e. it is responsible for freeing the pixmap. The problem for the owner is to determine when the transfer is complete and the pixmap can be freed. Our datatransfer is based on Xt selection handling architecture. It provides an API (XtSelectionDoneProc) to notify the owner that the transfer is complete. However XtSelectionDoneProc is called immediately after the transferred data is copied off by the requestor but before the XtSelectionCallbackProc is called on the requestor side. So if we free the pixmap in XtSelectionDoneProc, the XtSelectionCallbackProc will receive a freed pixmap and crash on an attempt to access it. So we would have to introduce additional hooks over the Xt selection to get rid of the resource leak. 3.Pixmap needs a Colormap to interpret its contents. Pixmap is just an array of pixel values. To get the real RGB triples we need to transfer the corresponding Colormap. So the correct transfer is to translate an Image to (Pixmap,Colormap) pair, transfer the pair and translate it back to the Image. This doesn't fit well with the data transfer system architecture and significantly complicates the code. Another problem was discovered while the suggested fix for this bug was tested : Xt can report that selection owner timed out when a large block of data is transferred and the X server connection is slow. Currently the Java data transfer subsystem doesn't handle this case properly and the diagnostics is incorrect: it reports a failure to convert the transferred data to some DataFlavor. ###@###.### 2002-02-12 ======================================================================
12-02-2002