RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v8]

Sergey Bylokhov serb at openjdk.org
Mon Jun 23 23:08:30 UTC 2025


On Mon, 16 Jun 2025 23:57:09 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> **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 one additional commit since the last revision:
> 
>   Enhance the test

test/jdk/java/awt/Frame/NotifyStressTest/NotifyStressTest.java line 57:

> 55:             for (int i = 0; i < 10; i++) {
> 56:                 f.removeNotify();
> 57:                 f.addNotify();

Note that we call addNotify last, so the frame will not be disposed at the end of the test.
btw, I cannot reproduce the bug even with the updated test. If you look at the stack trace, it seems the error comes from displayChanged, which is not triggered by the test itself

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2162664584


More information about the client-libs-dev mailing list