v3.6 crashes attempting to run example apps in fullscreen with LWJGL v2

[stephengold]

Investigating a possible regression in JME v3.6.0-alpha1, I tried to run some of the apps in jme3-examples in fullscreen mode ... for example jme3test.helloworld.HelloJME3 (though I ran into identical behavior with other example apps). Here's what happens:

• The display settings dialog appears with "Fullscreen" not checked and "Refresh Rate" blank.
• I check the box for "Fullscreen".
• The "Screen Resolution" changes to1920x1080 and the "Refresh Rate" changes to 55 Hz. Unfortunately, 55 Hz isn't a valid refresh rate for my display adapter. I believe the valid rates are 24, 30, and 60 Hz.
• When I try to select a different refresh rate, there are only 6 available options: 50 Hz, 51 Hz, 52 Hz, 53 Hz, 54 Hz, and 55 Hz. None of these are valid rates.
• After I click the "Continue" button, I get two "Error in Application" dialogs and the app crashes.

The console output is:

Jan 03, 2023 10:59:04 AM com.jme3.system.JmeDesktopSystem initialize
INFO: Running on jMonkeyEngine 3.6.0-alpha1
 * Branch: master
 * Git Hash: 5b9fc87
 * Build Date: 2023-01-03
Jan 03, 2023 10:59:05 AM com.jme3.app.LegacyApplication handleError
SEVERE: Failed to create display
java.lang.RuntimeException: Unable to find fullscreen display mode matching settings
	at com.jme3.system.lwjgl.LwjglDisplay.createContext(LwjglDisplay.java:80)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.initInThread(LwjglAbstractDisplay.java:120)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:221)
	at java.base/java.lang.Thread.run(Thread.java:833)

Jan 03, 2023 10:59:05 AM com.jme3.app.LegacyApplication handleError
SEVERE: Uncaught exception thrown in Thread[jME3 Main,5,main]
java.lang.IllegalMonitorStateException: current thread is not owner
	at java.base/java.lang.Object.notifyAll(Native Method)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.initInThread(LwjglAbstractDisplay.java:135)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:221)
	at java.base/java.lang.Thread.run(Thread.java:833)


Exception: java.lang.NullPointerException thrown from the UncaughtExceptionHandler in thread "jME3 Main"

Excerpt from glxinfo (to document my graphics configuration):

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GT 545/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 390.157
OpenGL core profile shading language version string: 4.60 NVIDIA

This was with "jme3-lwjgl" (LWJGL v2, which is currently the default jme3-examples build). Here's what happened when I switched the build to use "jme3-lwjgl3" (LWJGL v3):

• The display settings dialog appears with "Fullscreen" not checked and "Refresh Rate" blank.
• I check the box for "Fullscreen".
• The "Screen Resolution" changes to1920x1080 and the "Refresh Rate" changes to 55 Hz.
• When I try to select a different refresh rate, there are only 6 available options: 50 Hz, 51 Hz, 52 Hz, 53 Hz, 54 Hz, and 55 Hz.
• After I click the "Continue" button, the application runs fullscreen.

[Ali-RS]

Sounds like this is related to #947

Can you please check if this solution works for you: #947 (comment)

Edit:

The "Screen Resolution" changes to1920x1080

Also, can you try different resolutions and see if makes any difference?
In my case, the resolution changes to 1440, 900 when selecting "Fullscreen". And I get the same error when I click the "Continue" button but if I change it to something else (e.g 1024, 768) the error goes away.

[stephengold]

ertugrulcetin's solution doesn't work for me.

1280x960 screen resolution does work for me.

I think we can close this as a duplicate of #947.

[Ali-RS]

@stephengold, by the way, do you have a secondary monitor connected?

In my case, I am using an external monitor connected to my laptop. I noticed if I unplug that and use the laptop's built-in monitor then it works fine.

[stephengold]

only one monitor in my setup

[Ali-RS]

Can you please run this Linux command xrandr -q and post the result?

[stephengold]

sgold:~$ xrandr -q
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384
DVI-I-0 disconnected (normal left inverted right x axis y axis)
VGA-0 disconnected (normal left inverted right x axis y axis)
DVI-I-1 disconnected (normal left inverted right x axis y axis)
HDMI-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 853mm x 480mm
   1920x1080     60.00*+  59.94    29.97    23.98    60.05    60.00  
   1680x1050     59.95  
   1440x900      59.89  
   1440x480      60.05  
   1280x1024     60.02  
   1280x960      60.00  
   1280x800      74.93    59.81  
   1280x768      59.99  
   1280x720      60.00    59.94  
   1024x768      60.00  
   800x600       60.32    56.25  
   720x480       59.94  
   640x480       59.94    59.93  
sgold:~$ 

[Ali-RS]

@stephengold can you please test with this lwjgl jar and see if it fixes your issue?
lwjgl.zip

I have forked lwjgl2 and applied this patch provided by @riccardobl

Edit:
In my case the xrandr -q result is

Screen 0: minimum 320 x 200, current 1440 x 900, maximum 8192 x 8192
LVDS-1 connected (normal left inverted right x axis y axis)
   1366x768      60.00 +
   1360x768      59.80    59.96  
   1280x720      60.00    59.99    59.86    59.74  
   1024x768      60.04    60.00  
   960x720       60.00  
   928x696       60.05  
   896x672       60.01  
   1024x576      59.95    59.96    59.90    59.82  
   960x600       59.93    60.00  
   960x540       59.96    59.99    59.63    59.82  
   800x600       60.00    60.32    56.25  
   840x525       60.01    59.88  
   864x486       59.92    59.57  
   800x512       60.17  
   700x525       59.98  
   800x450       59.95    59.82  
   640x512       60.02  
   720x450       59.89  
   700x450       59.96    59.88  
   640x480       60.00    59.94  
   720x405       59.51    58.99  
   684x384       59.88    59.85  
   680x384       59.80    59.96  
   640x400       59.88    59.98  
   576x432       60.06  
   640x360       59.86    59.83    59.84    59.32  
   512x384       60.00  
   512x288       60.00    59.92  
   480x270       59.63    59.82  
   400x300       60.32    56.34  
   432x243       59.92    59.57  
   320x240       60.05  
   360x202       59.51    59.13  
   320x180       59.84    59.32  
VGA-1 connected primary 1440x900+0+0 (normal left inverted right x axis y axis) 408mm x 255mm
   1440x900      59.89*+  74.98  
   1280x1024     75.02    60.02  
   1280x960      60.00  
   1152x864      75.00  
   1024x768      75.03    70.07    60.00  
   832x624       74.55  
   800x600       75.00    60.32    56.25  
   640x480       75.00    59.94  
   720x400       70.08  
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)

As you can see the second monitor is my primary monitor but lwjgl2 was wrongly picking the first one.

Edit2:

This is the commit: https://github.com/Ali-RS/lwjgl/commit/fbeac9a69a347bf7d34a01931b8757fac5f8dd41

[stephengold]

can you please test with this lwjgl jar and see if it fixes your issue?

1. I unzipped the ZIP you suggested and moved the JAR to "lib/lwjgl.jar" .
2. I edited jme3-lwjgl/build.gradle to change

api 'org.lwjgl.lwjgl:lwjgl:2.9.3'

to

api 'lwjgl:lwjgl'

3. When I tried to run HelloJme3, I got:

Jan 05, 2023 9:28:30 AM com.jme3.system.JmeDesktopSystem initialize
INFO: Running on jMonkeyEngine 3.6.0-alpha1
 * Branch: master
 * Git Hash: 5b9fc87
 * Build Date: 2023-01-05
Exception in thread "jME3 Main" java.lang.UnsatisfiedLinkError: The required native library 'openal64' was not found in the classpath via 'native/linux/libopenal64.so'. Error message: no openal64 in java.library.path: /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib
	at com.jme3.system.NativeLibraryLoader.loadNativeLibrary(NativeLibraryLoader.java:590)
	at com.jme3.system.lwjgl.LwjglContext.loadNatives(LwjglContext.java:229)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:219)
	at java.base/java.lang.Thread.run(Thread.java:833)

4. I added

runtimeOnly 'org.lwjgl.lwjgl:lwjgl-platform:2.9.3:natives-linux'

(Are those the correct natives to use with your fork?)

5. When I ran HelloJME3 I still got invalid refresh rates and

Jan 05, 2023 10:05:06 AM com.jme3.system.JmeDesktopSystem initialize
INFO: Running on jMonkeyEngine 3.6.0-alpha1
 * Branch: master
 * Git Hash: 5b9fc87
 * Build Date: 2023-01-05
Jan 05, 2023 10:05:06 AM com.jme3.app.LegacyApplication handleError
SEVERE: Failed to create display
java.lang.RuntimeException: Unable to find fullscreen display mode matching settings
	at com.jme3.system.lwjgl.LwjglDisplay.createContext(LwjglDisplay.java:80)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.initInThread(LwjglAbstractDisplay.java:120)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:221)
	at java.base/java.lang.Thread.run(Thread.java:833)

Jan 05, 2023 10:05:06 AM com.jme3.app.LegacyApplication handleError
SEVERE: Uncaught exception thrown in Thread[jME3 Main,5,main]
java.lang.IllegalMonitorStateException: current thread is not owner
	at java.base/java.lang.Object.notifyAll(Native Method)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.initInThread(LwjglAbstractDisplay.java:135)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:221)
	at java.base/java.lang.Thread.run(Thread.java:833)


Exception: java.lang.NullPointerException thrown from the UncaughtExceptionHandler in thread "jME3 Main"

[Ali-RS]

Thanks so much for trying it.

Are those the correct natives to use with your fork?

Yes

When I ran HelloJME3 I still got invalid refresh rates and

I doubt in your case it might be the AWT that returns the wrong display modes that do not match with the display modes loaded by lwjgl2 (via xrandr).

[stephengold]

Both LWJGLv2 and LWJGLv3 provide methods to enumerate the available display modes. For my Acorus library, I wrote utility methods to dynamically determine which version(s) of LWJGL are available and invoke the appropriate method. It seems to work reliably.

I think we should do something similar for the v3.6 display-settings dialog.

[pspeed42]

Yes, I agree... it seems to be something we've been missing for a long time to be able to generically get a list of "GL library supported modes" without guessing by asking AWT.

[Ali-RS]

Good idea!

Edit:

Found the utility class you mentioned. Going to take a closer look at it.

https://github.com/stephengold/Acorus/blob/0a8331b07cbecb68fa7ffb12b7a10b6b3794c0ef/AcorusLibrary/src/main/java/jme3utilities/ui/DsUtils.java#L56

[stephengold]

I still think this is a duplicate of #947. Not sure why it got re-opened.

[Ali-RS]

Well, I believe the causes are different and need different treatments.
One is related to the AWT issue (yours) and one is that lwjgl2 takes the first display in the map as the primary display which is not always true. They both produce the same errors.

The later can simply be fixed by https://github.com/Ali-RS/lwjgl/commit/fbeac9a69a347bf7d34a01931b8757fac5f8dd41.

Please feel free to close this if you think otherwise.

[Ali-RS]

When I replace these lines

jmonkeyengine/jme3-awt-dialogs/src/main/java/com/jme3/awt/AWTSettingsDialog.java

Lines 246 to 248 in 9e54d44

	GraphicsDevice device = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
	modes = device.getDisplayModes();

with

modes = DsUtils.listDisplayModes().toArray(new DisplayMode[0]);

I get this error at runtime

Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: no lwjgl64 in java.library.path
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860)
	at java.lang.Runtime.loadLibrary0(Runtime.java:843)
	at java.lang.System.loadLibrary(System.java:1136)
	at org.lwjgl.Sys$1.run(Sys.java:72)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.lwjgl.Sys.doLoadLibrary(Sys.java:66)
	at org.lwjgl.Sys.loadLibrary(Sys.java:87)
	at org.lwjgl.Sys.<clinit>(Sys.java:117)
	at org.lwjgl.opengl.Display.<clinit>(Display.java:135)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:264)
	at com.jme3.util.DsUtils.<clinit>(DsUtils.java:92)
	at com.jme3.awt.AWTSettingsDialog.<init>(AWTSettingsDialog.java:247)
	at com.jme3.awt.AWTSettingsDialog$1.run(AWTSettingsDialog.java:162)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

[Ali-RS]

Calling DsUtils.listDisplayModes() after the app start works fine (e.g. inside simpleInitApp()) but if I call it before the app starts it gives the above error.

I guess that is because at that point the natives are not still loaded via NativeLibraryLoader which will happens only when the context is being created. (after calling to the app.start())

[stephengold]

Could you load the natives explicitly, before the app starts?

[Ali-RS]

I also tested with lwjgl3, and DsUtils.listDisplayModes() returns an empty array with lwjgl3 if called before app start.

Could you load the natives explicitly, before the app starts?

In the case of lwjgl2 if I add NativeLibraryLoader.loadNativeLibrary("lwjgl", false); before the app starts and before calling to DsUtils.listDisplayModes() it works fine and the crash goes away.

But with lwjgl3 if load natives (NativeLibraryLoader.loadNativeLibrary("lwjgl3", false);, NativeLibraryLoader.loadNativeLibrary("glfw-lwjgl3", false);) before app starts and before calling to DsUtils.listDisplayModes() it does not make any difference and still returns an empty array.

I made a test case

import com.jme3.app.SimpleApplication;
import com.jme3.awt.AWTSettingsDialog;
import com.jme3.system.NativeLibraryLoader;
import com.jme3.util.DsUtils;

import java.awt.*;
import java.util.Arrays;

/**
 * @author Ali-RS
 */
public class TestDsUtils extends SimpleApplication {

    public static void main(String[] args) {
        // Load Natives For LWJGL 2
        NativeLibraryLoader.loadNativeLibrary("lwjgl", false);

        // Load Natives For LWJGL 3
        NativeLibraryLoader.loadNativeLibrary("lwjgl3", false);
        NativeLibraryLoader.loadNativeLibrary("glfw-lwjgl3", false);

        System.out.println("Debugging Display Modes Before Start");
        debugDisplayModes(); // Does not work with LWJGL 3

        TestDsUtils app = new TestDsUtils();
        app.setShowSettings(false);
        app.start();

        System.out.println("Debugging Display Modes After Start");
        debugDisplayModes(); // Does not work with LWJGL 3
    }

    private static void debugDisplayModes() {
        DisplayMode[] modes = DsUtils.listDisplayModes().toArray(new DisplayMode[0]);//device.getDisplayModes();
        //Arrays.sort(modes, new AWTSettingsDialog.DisplayModeSorter());

        System.out.println("Num Modes:" + modes.length);
        for (DisplayMode mode : modes) {
            System.out.println("Size=[" + mode.getWidth() + "," + mode.getHeight() + "], refreshRate=" + mode.getRefreshRate() );
        }
    }

    @Override
    public void simpleInitApp() {
        System.out.println("Debugging Display Modes From simpleInitApp");
        debugDisplayModes();
    }
}

[stephengold]

LWJGL v3 loads its natives using a static initializer, so there's no need for us to explicitly load them. I suspect the test app fails with LWJGL v3 because GLFW.glfwInit() isn't invoked prior to DsUtils.listDisplayModes().

[Ali-RS]

I suspect the test app fails with LWJGL v3 because GLFW.glfwInit() isn't invoked prior to DsUtils.listDisplayModes().

You were right, if I call GLFW.glfwInit(); before DsUtils.listDisplayModes() then it works fine. I doubt that this has a breaking effect. (?)

[stephengold]

The cleanest solution, I think, would be to have 2 different settings dialogs: one for LWJGL v2 and one for LWJGL v3.

The one for LWJGL v2 could use AWT to create the dialog, but it would use org.lwjgl.opengl.Display.getAvailableDisplayModes() to enumerate display modes. That would address this issue.

The one for LWJGL v3 wouldn't use AWT at all.

[stephengold]

I doubt that this has a breaking effect.

There is a small amount of configuration that must occur prior to GLFW.glfwInit(), such as configuring GLFW debugging and "glfw_async". These would have to be configured using config files, environment variables, command-line arguments, etcetera instead of the settings dialog and AppSettings.

Or are you concerned about the possibility that glfwInit() might get invoked twice?

[Ali-RS]

Or are you concerned about the possibility that glfwInit() might get invoked twice?

Yes, this was one of the concerns. But seems calling it multiple times does not cause an issue, at least in my case.

The next concern is that glfwInit() must be called before doing anything with AWT. (I remember I have seen this mentioned somewhere by @Spasi)

So in the case of the TestChooser app it must be inside the main and in the case of AwtSettingsDialog, it must be before calling to this:

jmonkeyengine/jme3-awt-dialogs/src/main/java/com/jme3/system/JmeDialogsFactoryImpl.java

Line 41 in 00a8597

return AWTSettingsDialog.showDialog(settings,loadFromRegistry);

otherwise, it crashes the app in my case with these errors:

X Error of failed request:  RenderBadPicture (invalid Picture parameter)
  Major opcode of failed request:  139 (RENDER)
  Minor opcode of failed request:  7 (RenderFreePicture)
  Picture id in failed request: 0x4000024
  Serial number of failed request:  1452
  Current serial number in output stream:  1458

and

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fce4acf3fc4, pid=11844, tid=0x00007fce2056c700
#
# JRE version: OpenJDK Runtime Environment (8.0_352-b08) (build 1.8.0_352-b08)
# Java VM: OpenJDK 64-Bit Server VM (25.352-b08 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libpthread.so.0+0xbfc4]  pthread_mutex_lock+0x4
#

I created DsUtils.initNatives(), if I call it in TestChooser.main() and JmeDialogsFactoryImpl.showSettingsDialog() it works fine and no crash happens.

    /**
     * Call this only when app has not started yet (e.g. when requesting
     * display modes from settings dialog).
     */
    public static void initNatives() {
        if (initializedNatives) {
            return;
        }
        
        if (hasLwjglVersion3()) {
            try {
                Class<?> glfwClass = Class.forName("org.lwjgl.glfw.GLFW");
                Method glfwInit = glfwClass.getDeclaredMethod("glfwInit");
                glfwInit.invoke(null);
            } catch (ClassNotFoundException | NoSuchMethodException | InvocationTargetException |
                     IllegalAccessException exception) {
                throw new RuntimeException(exception);
            }
        } else if (hasLwjglVersion2()) {
            NativeLibraryLoader.loadNativeLibrary("lwjgl", true);
        }

        initializedNatives = true;
    }

P.S:

off-topic
If I had a mac to test, I would definitely try glfwInit() at the main method at the very beginning and before calling to app.start() to see if it fixes the mac + jme awt settings dialog issue as well.

[Ali-RS]

The cleanest solution, I think, would be to have 2 different settings dialogs: one for LWJGL v2 and one for LWJGL v3.

Agree with you.
I can copy those 3 classes from jme3-awt-dialogs module (AWTErrorDialog, AWTSettingsDialog, JmeDialogsFactoryImpl) into jme3-lwjgl module and change it to use org.lwjgl.opengl.Display.getAvailableDisplayModes() or do you prefer a separate module jme3-lwjgl-dialogs for that?

By the way, another simple trick also could be to just ignore the passed "refresh rate" in LwjglDisplay.createContext() if it is wrong when running in full-screen and just print a console log instead of throwing an exception. I guess that is why lwjgl3 does not crash in your case even if the refresh rate passed is wrong, probably it just ignores the hint (if wrong?) when in fullscreen.

Edit:
But before proceeding with any of these solutions @stephengold would you please try your test once more with the new lwjgl-2.9.4 available from Sonatype and see if this error still happens?

[Ali-RS]

Yet another solution is to do something like @riccardobl did with JmeDialogsFactory and JmeDialogsFactoryImpl. We can create an interface DisplayModesLoader and provide the implementation in jme3-lwjgl module. AWTSettingsDialog class then will first need to look on the classpath for a DisplayModesLoaderImpl and if it found one it will use it if no implementation is found then will fall back to using AWT GraphicsEnvironment. Any thought?

[Ali-RS]

On the other hand, see the java doc for org.lwjgl.opengl.Display.getAvailableDisplayModes()

https://github.com/jMonkeyEngine/lwjgl2/blob/97363d3f49016abde565e767a8bbd685cc920439/src/java/org/lwjgl/opengl/Display.java#L171-L186

any given mode is not guaranteed to be available nor is it guaranteed to be within the
current monitor specs (this is especially a problem with the frequency parameter).
Furthermore, it is not guaranteed that create() will detect an illegal display mode.

this makes me feel that we might get from one hole to another! and cause me to reconsider this solution:

By the way, another simple trick also could be to just ignore the passed "refresh rate" in LwjglDisplay.createContext() if it is wrong when running in full-screen and just print a console log instead of throwing an exception. I guess that is why lwjgl3 does not crash in your case even if the refresh rate passed is wrong, probably it just ignores the hint (if wrong?) when in fullscreen.

[stephengold]

we might get from one hole to another!

Based on my experience, if org.lwjgl.opengl.Display.getAvailableDisplayModes() puts us in a hole, it will be a much shallower hole than the one AWT has put us in.

LWJGL and AWT do not play nicely together.

[Ali-RS]

I submitted a shallow fix in #1898

It just gets rid of the exception to let the app continue running. For a proper solution, I will let someone else handle that.

[stephengold]

Yet another solution is to do something like riccardobl did with JmeDialogsFactory and JmeDialogsFactoryImpl.

I would be okay with that.

[Ali-RS]

I would be okay with that.

Are you willing to prototype the interface in question? so I can provide an implementation based on it.

Edit:
Also, please note that we would still need to load lwjgl2 natives to be able to use org.lwjgl.opengl.Display.

[stephengold]

Are you willing to prototype the interface in question?

I'd rather not. Designing Java interfaces is not my strength, and I have many other tasks in my queue.