RFR: JDK-8357082 : Stabilize and add debug logs to CopyAreaOOB.java

[Alexey Ivanov]

On Tue, 27 May 2025 23:51:05 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> @mrserb 
>> 
>> I can remove the EDT but I do think retaining them will stabilize this test based on the context of test failure.
>> 
>> - Test does NOT fail when it is run multiple times on macos-aarch64 but only when entire test suite is run. Can it still be synchronization issue if it is not reproducible when test is run multiple times?   
>> 
>> - The test repeated fails on macos-aarch64 only when the entire test suite is run so I suspect this could be the effect of couple of Graphics tests that was recently open-sourced and indeed this matches with the timeline that this test started to fail repeatedly on macos-aarch64.
>> 
>> - I didn't see any recent source code changesets that has direct relation to this test failure. There was one recent change to copyArea and ongoing subsequent change https://github.com/openjdk/jdk/pull/25340 but the test does not hit the code path in Blit.c or MaskBlit.c so that eliminates these changes as the cause.
>
> At the very least this test requires to be de-problemlisted to obtain the screenshots at the time of failure to see the state of the Frame.
> 
> This test repeatedly fails due to the same error at the same point (at x=267 y=212) which is about mid-way of the frame where the color is expected to be black but the actual is white.
> 
> 
> java.lang.RuntimeException: Test failed for background region at x=267 y=212 (expected=ff000000 actual=ffffffff)
> at CopyAreaOOB.testRegion(CopyAreaOOB.java:97)
> at CopyAreaOOB.paint(CopyAreaOOB.java:77) 
> 
> 
> **Expected Frame**
> 
> <img src="https://github.com/user-attachments/assets/b0af326e-f99f-474b-81a8-bb110cb0a37c" alt="background" width="150" height="150">

@honkar-jdk This does seem weird… Since the test is _headful_, it starts a new JVM for each execution and the JVM is shut down after the `main` method exits. I don't think the test runs long enough for synchronisation issues to manifest themselves, especially during the initial startup.

At the same time, aarch64 is usually more sensitive to the lack of proper synchronisation than x86_64.

If the test test fails only when it's run together with other tests in CI, could it be that the test frame is covered by anything?

Re: `expected=ff000000 actual=ffffffff` — I can't see a while pixel on the screenshot. Does the test save both images: the expected and the actual one?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2111744123