JDK-4392080 : JCK interactive: jck13a test api/java_awt/interactive/RobotTests.html fail
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.1
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2000-11-23
  • Updated: 2019-09-19
  • Resolved: 2001-01-31
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 Other
1.3.1 ladybirdFixed 1.4.0Fixed
Related Reports
Relates :  
Description

The following JCK13a testcases fail under build 1.3.1beta-b08 in RedHat 6.2:
api/java_awt/interactive/RobotTests.html#RobotTests0001
api/java_awt/interactive/RobotTests.html#RobotTests0002

Bug Description:
1) The getPixelColor() method  of Robot class returns wrong color value
   of the pixel. It does not return red and green values.
2) The createScreenCapture() method returns wrong screen capture.
   It returns only blue part, but red and green does not.

To reproduce the bug, run script below 
You may need to set JCK and JAVA_HOME.
-------------------------------------------------------------------------------------
#!/bin/sh
SWITCH=${@}
JAVA_HOME=/usr/local/java/jdk1.3.1/linux-i386
JCK=/net/jtgb4u4c.eng/export/sail16/JCK/jck13afcs/JCK-runtime-13fcs

CLASSPATH=${JCK}/classes:${JCK}/javatest.jar
export CLASSPATH
executeClass=javasoft.sqe.tests.api.java.awt.interactive.RobotTests

$JAVA_HOME/bin/java ${SWITCH} -version
$JAVA_HOME/bin/java ${SWITCH} -client -Xfuture ${executeClass} -platform.robotAvailable true -TestCaseID ALL
RESULT="$?"
if [ $RESULT = 95 ]; then
 echo Test passed
elif [ $RESULT = 97 ]; then
 echo Test failed
else
 echo Result is $RESULT
fi
-------------------------------------------------------------------------------------

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: ladybird merlin FIXED IN: ladybird merlin-beta INTEGRATED IN: ladybird merlin-beta VERIFIED IN: ladybird-beta merlin-beta
14-06-2004

EVALUATION Commit to Ladybird and Merlin (JCK failure). eric.hawkes@eng 2000-11-30 This is reproducible on 6.2 and 6.1 when running in 24 bit mode. 256 color mode does not exhibit this problem. brent.christian@eng 2000-11-30 This is a problem with the QueryColorMap function in src/solaris/native/sun/awt/robot_child/multiVis.c. The following was added for the Linux JDK: #ifdef __linux__ colors[i].pixel = i; #endif This was added to avoid the following error when running in 16-bit mode: X Error of failed request: BadValue (integer parameter out of range for opera tion) Major opcode of failed request: 91 (X_QueryColors) Value in failed request: 0x7c71b Serial number of failed request: 1244 However, the change made to fix 16-bit breaks these tests when running 24-bit. Removing the #ifdefed code fixes 24-bit. The BadValue was happening because the XColor array allocated in QueryColorMap was never initialized: *src_colors = colors = (XColor *)calloc(ncolors,sizeof(XColor) ) ; The pixel member of the XColor structure is set in the following loop: for (i=0; i<ncolors; i++) { if( i <= redMask)colors[i].pixel = (i<<redShift) ; if( i <= greenMask)colors[i].pixel |= (i<<greenShift) ; if( i <= blueMask)colors[i].pixel |= (i<<blueShift) ; Note that if redMask < i <= greenMask that pixel is not initialized, but only ORed with (i<<greenShift). In 16-bit mode, 5 bits each are allocated to red and blue, while green has 6 bits. The color masks are shifted into the least significant bits by the following code, which calculates the color shifts: redShift = 0; while (!(redMask&0x1)) { redShift++; redMask = redMask>>1; } greenShift = 0; while (!(greenMask&0x1)) { greenShift++; greenMask = greenMask>>1; } blueShift = 0; while (!(blueMask&0x1)) { blueShift++; blueMask = blueMask>>1; } So in 16-bit mode, redMask will end up being 0x1F while greenMask is 0x3F. When i = 0x20, the garbage in colors[i].pixel is never cleared out, and eventually is passed into XQueryColors(), often causing the X error. The solution is twofold: initialize the XColor array (to keep 16-bit mode from crashing), and remove the #ifdef pixel assignment (to get 24-bit to work). *************** *** 217,228 **** ncolors = src_vis->map_entries ; ! *src_colors = colors = (XColor *)malloc(ncolors * sizeof(XColor) ) ; if(src_vis->class != TrueColor && src_vis->class != DirectColor) { --- 217,228 ---- ncolors = src_vis->map_entries ; ! *src_colors = colors = (XColor *)calloc(ncolors,sizeof(XColor) ) ; if(src_vis->class != TrueColor && src_vis->class != DirectColor) { *************** *** 261,269 **** /***** example :for gecko's 3-3-2 map, blue index should be <= 3 . colors[i].pixel = (i<<redShift)|(i<<greenShift)|(i<<blueShift) ; *****/ - #ifdef __linux__ - colors[i].pixel = i; - #endif colors[i].pad = 0; colors[i].flags = DoRed|DoGreen|DoBlue; }
11-06-2004

SUGGESTED FIX ------- multiVis.c ------- *************** *** 217,228 **** ncolors = src_vis->map_entries ; ! *src_colors = colors = (XColor *)malloc(ncolors * sizeof(XColor) ) ; if(src_vis->class != TrueColor && src_vis->class != DirectColor) { --- 217,228 ---- ncolors = src_vis->map_entries ; ! *src_colors = colors = (XColor *)calloc(ncolors,sizeof(XColor) ) ; if(src_vis->class != TrueColor && src_vis->class != DirectColor) { *************** *** 261,269 **** /***** example :for gecko's 3-3-2 map, blue index should be <= 3 . colors[i].pixel = (i<<redShift)|(i<<greenShift)|(i<<blueShift) ; *****/ - #ifdef __linux__ - colors[i].pixel = i; - #endif colors[i].pad = 0; colors[i].flags = DoRed|DoGreen|DoBlue; }
11-06-2004