RFR: 8185862: AWT Assertion Failure in ::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0) 'awt_Win32GraphicsDevice.cpp', at line 185 [v5]

[Phil Race]

On Fri, 16 Feb 2024 13:26:19 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> The assertions reported in the bug were observed spuriously and here and there broke tests in some Windows configurations.
>> For instance [JDK-8266129](https://bugs.openjdk.org/browse/JDK-8266129), [JDK-8269529](https://bugs.openjdk.org/browse/JDK-8269529) or [JDK-8323664](https://bugs.openjdk.org/browse/JDK-8323664) came up due to this.
>> 
>> The problem is that in Windows environments without a valid display, e.g. started by system services or via PowerShell Remoting, one sees a Monitor with name 'Windisc' in `EnumDisplayMonitors`.
>> However, it seems to be some kind of a pseudo device where you can not get a DC via `CreateDC`. This behavior/monitor type doesn't seem to be well documented, though.
>> 
>> I hereby modify the device initialization code to only count/detect monitors where CreateDC returns non-NULL in Devices.cpp. I also add some more checking/error handling to AwtWin32GraphicsDevice::Initialize() for correctness.
>> 
>> Furthermore, I re-enable the test `javax/swing/reliability/HangDuringStaticInitialization.java` for Windows Debug VMs, which reverts the fix from JDK-8269529 that should not be necessary any more.
>
> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Get rid of global variables and restore old handling wrt calling ::GetDIBits
>  - Merge branch 'master' into JDK-8185862
>  - Little cleanup
>  - Review Feedback Alexey
>  - Merge branch 'master' into JDK-8185862
>  - Add comments
>  - JDK-8185862

This all looks reasonable initself but .. 
The first thing I worry about here is that the obvious implication is that we can now have zero monitors.
Even if the monitor were not usable, that seems to have been "OK" in practice so long as we didn't assert out in a debug build.
Have you looked for any subsequent code that might break  with zero monitors ?

The 2nd thing is that this situation ought to clearly flag that this is a HEADLESS situation and the AWT should be in headless mode.
And that decision usually needs to be made very early. So is this code path involved in that decision.
It seems likely there's a missing piece since I don't know that we even properly make that decision on windows like we do on Linux.

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

PR Comment: https://git.openjdk.org/jdk/pull/17614#issuecomment-1949383141