Hello Phil,
I tried to apply your code and can confirm that value of "color" is
always the same for the case, when the test passes and fails. For each
test run the "paint(Graphics)" method is called either 2 or 3 times and
this tracing output is always the same and following:
"color=java.awt.Color[r=255,g=255,b=255] alpha=127"
My today's experiments show that this intermittent failure is
reproducible with builds prior to the builds with the fix for 8214579
and this is also reproducible on Oracle Linux 7.4 x64. I was able to
reproduce in the following environment configurations:
1. Oracle Linux 7.4 x64 with JDK 13+23 (the build without the fix
8214579 which was integrated in JDK 13+24)
2. openSUSE Leap 15.0 with JDK 13+23, JDK 11+25 (build in which the test
itself was introduced), JDK 11+28 (GA build).
I attached a screenshot with the test failure and wrote a comment in the
bug (https://bugs.openjdk.java.net/browse/JDK-8224825).
MY OBSERVATION:
Although I have not been able to identify the root cause of the
intermittent test failure, I think that the wrong color is got, when the
black color, which is set as the background for the frame, is not
participating in color blending.
THE DISCOVERED WORKAROUND:
I discovered that if the following workaround is applied to the
regression test "test/jdk/java/awt/Color/AlphaColorTest.java", then the
intermittent test failure disappears (is not reproducible, when test is
run 20 times in a row). Also I verified with the workaround the test
fails as it should with JDK 11+24 (the build without the fix 8204931
which was integrated in JDK 11+25 and introduced the test). The
workaround is following.
Substitute the next 2 code lines:
77 frame = new Frame("Alpha Color Test");
78 frame.setBackground(Color.black);
for the next 8 code lines:
frame = new Frame("Alpha Color Test") {
@Override
public void paint(Graphics g) {
g.setColor(Color.black);
g.fillRect(0, 0, getWidth(), getHeight());
super.paint(g);
}
};
Would such a workaround be acceptable as part of this back out fix?
Thank you,
Anton
On 11/07/2019 19:48, Phil Race wrote:
I don't think we ever saw it fail until 8214579 was pushed.
I don't know the reason for the color you are sporadically getting in VB
Maybe it is slow and the paint event is being missed ?
But then I'd expect black .. not light grey.
Still, it might be informative to put a print statement in here (in
the test)
public void paint(Graphics g) {
System.out.println("color=" + color + " alpha=" +
color.getAlpha()); // << add this
g.setColor(color);
g.fillRect(0, 0, getSize().width, getSize().height);
}
and compare what is printed for failing and passing runs.
If you can't figure it out quickly, then update the test to not exit
so quickly and grab a screen
shot of the failure and add it to the bug.
-phil.
On 7/11/19 11:13 AM, Anton Litvinov wrote:
Hello Phil,
Thank you for these additional details. I have tried to run the test
"open/test/jdk/java/awt/Color/AlphaColorTest.java" with JDK 13
compiled from "jdk/jdk13" with/without this back out fix and the
results are not so stable on my VirtualBox host with openSUSE Leap
15.0 OS (GNOME 3.26.2):
1. "AlphaColorTest.java" stably fails with JDK 13 without this back
out fix and the test failure message is stably:
"Color is not as expected. Got java.awt.Color[r=255,g=255,b=255]"
2. "AlphaColorTest.java" starts passing with JDK 13 with the back out
fix, but continues to intermittently fail with the failure message:
"Color is not as expected. Got java.awt.Color[r=189,g=189,b=189]"
It looks that either this regression test had been failing
intermittently before the fix 8214579, which we are backing out, was
integrated, or some other fix causes this intermittent failure.
Maybe in this case it is better not to change this
"open/test/jdk/ProblemList.txt" as well as the test itself
"open/test/jdk/java/awt/Color/AlphaColorTest.java" as part of this
back out fix for JCK test failure?
Thank you,
Anton
On 11/07/2019 17:38, Philip Race wrote:
There is a regression test that is supposed to catch this exact
problem.
So I had looked into how we did not catch this earlier and found
that in fact we did.
This was originally found and filed as
https://bugs.openjdk.java.net/browse/JDK-8224825
The test java/awt/Color/AlphaColorTest.java was then problem listed
on Linux.
$ grep AlphaColorTest test/jdk/ProblemList.txt
java/awt/Color/AlphaColorTest.java 8224825 linux-all
So I think we can close JDK-8224825 as a duplicate of this as well
as updating the problem list
and the test - after confirming that this backout resolves that as I
expect it will.
-phil.
On 7/11/19, 9:20 AM, Anton Litvinov wrote:
By your request regenerated the webrev specifically against
(http://hg.openjdk.java.net/jdk/jdk13) repository.
JDK 13 specific webrev:
http://cr.openjdk.java.net/~alitvinov/8227392/jdk13/webrev.00
I confirm again, that 2 failing manual tests: "ColorTest0003",
"ColorTest0004" from the test
"api/java_awt/interactive/ColorTests.html" in JCK 13 do not fail
anymore after this fix is applied to JDK 13 compiled from
"jdk/jdk13" repository.
"jdk/jdk13" repository does not contain any problem list mentioning
"api/java_awt/interactive/ColorTests.html" test from JCK 13, thus I
cannot de-problem list it and have no idea, where it is
problem-listed. I also doubt that it is problem-listed, since it is
manual. I added "noreg-jck" label to the bug in JBS deliberately
according to OpenJDK process (Section #6 from the web page
(http://openjdk.java.net/guide/changePlanning.html)), because this
back out fix does not contain a new separate regression test, while
this regression can be checked by running existing mentioned above
test from JCK package.
If this "noreg-jck" label creates problems, I can remove it at all.
Thank you,
Anton
On 11/07/2019 15:51, Philip Race wrote:
One more thing I just realised you should do here is de-problem list
the regression test that fails ... after verifying it now works,
updating it with this bug ID.
And you can remove that noreg-jck label as a consequence.
-phil.
On 7/11/19, 7:35 AM, Philip Race wrote:
In such cases I like more than to be told "it would apply
cleanly" but also to see
that you actually prepared the webrev against 13. This is more
certain
and ensures that when the fix is approved you don't accidentally
push it
to the wrong repo. You have to go clone 13 and apply the patch
there anyway ...
-phil.
On 7/11/19, 5:44 AM, Anton Litvinov wrote:
Hello Phil,
Thank you for review and the important remark about the need to
work with "jdk/jdk13" stabilization repository, I forgot about
this feature of post RDP 1 phase. Today I checked the fix
against "jdk/jdk13" repository and confirm that it resolves this
bug for JDK 13.
Will wait for feedback or approval from any other second code
reviewer.
Thank you,
Anton
On 10/07/2019 19:55, Phil Race wrote:
Anton,
This looks fine except that it needs to be prepared against 13,
and then pushed there, not 14.
And it will get forwarded synced from 13 to 14. That is the RDP
process ..
-phil.
On 7/10/19 5:00 AM, Anton Litvinov wrote:
Hello,
Could you please review the following fix for the bug. The fix
is backing out of the fix for the bug JDK-8214579 which caused
this JCK test failure. If this fix is accepted, then a new
separate bug for readdressing the bug reported in JDK-8214579
will be filed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8227392
Webrev:
http://cr.openjdk.java.net/~alitvinov/8227392/jdk14/webrev.00
Changeset of JDK-8214579:
http://hg.openjdk.java.net/jdk/client/rev/c53905e7dc57
Thank you,
Anton
