> **Analysis:**
>
> We are encountering a race condition in the native code. While retrieving the
> screen number by calling _getScreenImOn(), the window is disposed. As a
> result, the AWT-Windows event loop processes the Dispose() call, which
> triggers UnlinkObjects().
> The race condition between the execution paths of these two native methods
> sometimes causes an exception
>
> **Proposed Fix:**
>
> While it's possible to introduce a synchronization mechanism, it would not
> offer any real benefit. The window will be disposed regardless, and we’ll
> fall back to the default screen. This behavior is already handled in
> WWindowPeer.java, where a workaround is in place to use the default device
> when getScreenImOn() returns a non-existent screen number
>
>
> public void updateGC() {
>
> int scrn = getScreenImOn();
>
> if (screenLog.isLoggable(PlatformLogger.Level.FINER)) {
> log.finer("Screen number: " + scrn);
> }
>
> // get current GD
> Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice();
>
> Win32GraphicsDevice newDev;
> GraphicsDevice[] devs = GraphicsEnvironment
> .getLocalGraphicsEnvironment()
> .getScreenDevices();
>
> // Occasionally during device addition/removal getScreenImOn can return
> // a non-existing screen number. Use the default device in this case.
> if (scrn >= devs.length) {
> newDev = (Win32GraphicsDevice) GraphicsEnvironment
> .getLocalGraphicsEnvironment().getDefaultScreenDevice();
> } else {
> newDev = (Win32GraphicsDevice) devs[scrn];
> }
> }
>
>
> Therefore, I propose modifying the native method getScreenImOn to return the
> default device if the peer is being disposed :
>
> jint AwtWindow::_GetScreenImOn(void *param)
> {
> ...
> jboolean destroyed = JNI_GET_DESTROYED(self);
> if (destroyed == JNI_TRUE){
> env->DeleteGlobalRef(self);
> return AwtWin32GraphicsDevice::GetDefaultDeviceIndex();
> }
> ...
>
>
> **Tests Summary:**
>
> GetGraphicsStressTest (existing test):
>
> Fails intermittently without the fix
>
> Consistently passes with the fix
>
> NotifyStressTest (newly added test):
>
> Consistently fails without the fix
>
> Consistently passes with the fix
Anass Baya has updated the pull request incrementally with two additional
commits since the last revision:
- Add the new bug ID to the old test
- Reorder declaration
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/25619/files
- new: https://git.openjdk.org/jdk/pull/25619/files/3175a0f2..bfc4ac18
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=05
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=04-05
Stats: 12 lines in 2 files changed: 4 ins; 4 del; 4 mod
Patch: https://git.openjdk.org/jdk/pull/25619.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/25619/head:pull/25619
PR: https://git.openjdk.org/jdk/pull/25619
