JDK-8230782 : Robot.createScreenCapture() fails if ���awt.robot.gtk��� is set to false
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 8u221,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • Submitted: 2019-09-10
  • Updated: 2020-07-27
  • Resolved: 2019-09-23
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.
JDK 11 JDK 13 JDK 14 JDK 7 JDK 8 Other
11.0.6-oracleFixed 13.0.2Fixed 14 b16Fixed 7u291Fixed 8u241Fixed openjdk8u262Fixed
Related Reports
Relates :  
Relates :  
Description
Robot.createScreenCapture() gets the wrong colours if the option awt.robot.gtk is set to false, see attachments. The problem is reproducible on Linux (e.g. Ubuntu 18.04) in VNC environment when server depth is set to 16.

Steps to reproduce:
1. Start VNC server, (e.g. vncserver :18 -depth 16 &)
2. Start VNC client, (e.g. gvncviewer localhost:18 &)
3. Run RobotScreenCaptureTest.java, (i.e. java -Dawt.robot.gtk=false RobotScreenCaptureTest)
Note: it might be necessary to repeat step 3 several times (~10) to reproduce the issue

Actual result:
The test fails due to wrong colour, see ���screenCapture_awt.robot.gtk=false.png��� in the attachment

Expected result:
The test should pass, see ���screenCapture_awt.robot.gtk=true.png��� in the attachment
Comments
Fix request (8u) I would like to backport this patch to 8u, as it is in Oracle's 8u241. The patch applies cleanly after JDK-8210776 backport.
16-12-2019

[~dmarkov] Thanks, Dmitry
16-12-2019

[~zgu] JDK-8210776 was ported to 8u, but the backport was closed. I have opened it, see JDK-8218149
16-12-2019

[~dmarkov] I am confused. You mentioned above, that the problem was caused by JDK-8210776. But I don't see 8u backport of JDK-8210776, why this bug shows up in 8u221? Thanks.
13-12-2019

Fix request (11u) I am looking at this issue. The error fixed here was only introduced by "JDK-8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7", which is closed, though. Thus, we can not see whether it was downported, but as the fix is in 11.0.6-oracle, 8210776 must be there, too. I asked to open the bug: http://mail.openjdk.java.net/pipermail/jdk-dev/2019-November/003633.html Both changes apply clean.
21-11-2019

URL: https://hg.openjdk.java.net/jdk/jdk/rev/fe46ee1d42ee User: psadhukhan Date: 2019-09-25 09:20:40 +0000
25-09-2019

Fix Request (13u) - Justification: The changes fix the regression introduced by JDK-8210776 - Risk Analysis: Low, one-line change in multiVis.c - Testing: The fix may be verified using the test attached to the bug (see steps to reproduce above) The patch from jdk-dev (14) applies cleanly to 13u.
23-09-2019

URL: https://hg.openjdk.java.net/jdk/client/rev/fe46ee1d42ee User: dmarkov Date: 2019-09-23 16:19:22 +0000
23-09-2019

The bug agains XWD - https://gitlab.freedesktop.org/xorg/app/xwd/issues/3
20-09-2019

I am adding noreg-hard label since the problem is only reproducible in VNC environment
19-09-2019

Problem description: After integration of JDK-8210776 we started to use malloc() function for allocation of XColor array in QueryColorMap(). However malloc() does not initialise allocated memory. So if the memory contains some ���garbage��� we may get incorrect data inside the array. As a result Robot.createsScreenCapture() retrieves incorrect colours. Fix: It is necessary to either fill the allocated memory with 0 using memset() or invoke calloc() for allocation as it used to be.
19-09-2019

The problem was triggered by JDK-8210776
19-09-2019

The problem is reproducible on jdk8u221, jdk11.0.5, jdk12.0.2, jdk13 and jdk14. On 8u221 the test fails regardless the value of awt.robot.gtk option.
19-09-2019