search

libgdx / libgdx

Desktop/Android/HTML5/iOS Java game development framework
http://www.libgdx.com/
Apache License 2.0
23.09k stars 6.42k forks source link

LWJGL3 fails to create GLFW window when out of disk space? #6684

Open Frosty-J opened 2 years ago

Frosty-J commented 2 years ago

Last night we were speaking with Vince on Discord in #general. There's also an older "gdx-liftoff NullPointerException" thread in #help.

It's possible his computer's just completely screwed, but I'd like to document the noteworthy parts here, mainly in case anyone in future has the same issue, at which point the Discord messages will have been lost to time (and they can't be viewed publicly anyway). I don't mind if this issue gets closed, so long as it remains available for viewing.

Issue details

LWJGL3 does not work. But LWJGL2 does work, as do games, and I guess the rest of your usual everyday computer activities also work.

He was having issues installing(/updating?) GeForce Game Ready graphics drivers, but I'm uncertain that's related due to the fact LWJGL2 works and normally you'd also get Description : WGL : The driver does not appear to support OpenGL and a GdxRuntimeException: Couldn't create window if OpenGL is broken, neither of which happened here. Though it's basically our only lead.

Both gdx-setup's output project and gdx-liftoff (the tool itself - not its output, as the tool couldn't be run due to the same error) were tested, and LWJGL3 was enabled for the project using the instructions on the website.

Reproduction steps/code

Run a LWJGL3 libGDX application on his computer (yeah... I doubt anyone would manage to reproduce it intentionally). It's unknown if non-libGDX LWJGL3 stuff is also broken, but I think it's likely.

This was tested on both Corretto 14 and AdoptOpenJDK 14.

Version of libGDX and/or relevant dependencies

1.10.0, I think also 1.9.11... maybe every version of libGDX that supports LWJGL3.

Stack trace

Exception in thread "main" java.lang.NullPointerException
    at org.lwjgl.system.Checks.check(Checks.java:100)
    at org.lwjgl.glfw.GLFW.nglfwGetMonitorWorkarea(GLFW.java:1127)
    at org.lwjgl.glfw.GLFW.glfwGetMonitorWorkarea(GLFW.java:1158)
    at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.createGlfwWindow(Lwjgl3Application.java:482)
    at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.createWindow(Lwjgl3Application.java:404)
    at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.createWindow(Lwjgl3Application.java:390)
    at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lwjgl3Application.java:111)
    at com.mygdx.game.desktop.DesktopLauncher.main(DesktopLauncher.java:10)
AL lib: (EE) alc_cleanup: 1 device not closed

Affected platforms

Update

After resolving itself like magic, the new theory is this was caused by a lack of disk space. If this is the case, perhaps LWJGL3 could use the libraries from the JAR instead of first copying them (what is this reason for this - faster access speeds?) or simply give a warning if the user has less than, say, 10MB available on their C: drive or equivalent.

tommyettinger commented 2 years ago

Well Liftoff's current version uses libGDX 1.10.0, so we can confirm 1.10.0 as being affected on this machine. The used LWJGL3 version changed a while ago (some time after 1.9.10, and before 1.10.0), I think, so the line numbers in the stacktrace would be different for an older version. We had offered that maybe he had a headless JRE, but I don't think that proved to be the case. This is an extremely strange bug, and I wonder if there's some issue with the GPU involved because new drivers refuse to install.

Frosty-J commented 2 years ago

The used LWJGL3 version changed a while ago (some time after 1.9.10, and before 1.10.0), I think, so the line numbers in the stacktrace would be different for an older version.

Yeah, they're a bit different. Here's his Liftoff stack trace for comparison (I know you could find it, but the GitHub dwellers mightn't):

Exception in thread "main" java.lang.NullPointerException
    at org.lwjgl.system.Checks.check(Checks.java:100)
    at org.lwjgl.glfw.GLFW.nglfwGetMonitorWorkarea(GLFW.java:1127)
    at org.lwjgl.glfw.GLFW.glfwGetMonitorWorkarea(GLFW.java:1158)
    at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.createGlfwWindow(Lwjgl3Application.java:491)
    at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.createWindow(Lwjgl3Application.java:415)
    at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.createWindow(Lwjgl3Application.java:401)
    at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lwjgl3Application.java:113)
    at com.github.czyzby.setup.MainKt.main(main.kt:101)
    at com.github.czyzby.setup.MainKt.main(main.kt)

We had offered that maybe he had a headless JRE, but I don't think that proved to be the case.

I don't think this would matter anyway. LWJGL3 worked for me with openjdk11-jre-headless. I know it's not exactly the same. Point is, I think headless only matters for LWJGL2, where you get a Exception in thread "LWJGL Application" java.lang.UnsatisfiedLinkError: Can't load library: /usr/lib/jvm/java-11-openjdk-amd64/lib/libawt_xawt.so or similar if using it. I haven't and won't go testing that with every JRE on every OS. Though I expect there are circumstances where a headless JRE wouldn't work with LWJGL3, such as when using gdx-dialogs.

This is an extremely strange bug

I agree. We might not get anywhere. Still, I'm intrigued, and would like to get to the bottom of it.

tommyettinger commented 2 years ago

I think if users have next-to-no disk space left, a lot of things in the OS could fail, and that might be the first sign they get to check something. I think I recall the pagefile.sys and hiberfile.sys files in Windows complaining when they couldn't resize to fit my current memory usage. I'm not sure it's libGDX's responsibility for users to have a functioning machine -- if they do launch the game, and it uses 20MB of memory while they only have 10MB of storage left, and they put the computer to sleep with it open, the hiberfile.sys or comparable storage of sleeping programs wouldn't fit on disk, and that could be rather bad (probably the computer would just shut down, losing all sleeping programs). We don't put in checks that make sure users have a motherboard installed, so we probably don't need checks for full drives (especially if the user has a secondary drive that isn't full).

Frosty-J commented 2 years ago

I've had Windows with a full drive before, though not for any real length of time. Like you say, it's not a good experience, especially since drives were mostly mechanical in those days. I think it just didn't hibernate when there wasn't enough storage (black screen, then back to your windows after it gave up). Which was fine - could always use sleep mode (not hybrid sleep) or shut down instead.

It's not the only potential scenario - someone might have a read-only filesystem, such as if they've booted off a live CD. Certainly not a scenario the average user would be in, I know.

No matter how tongue-in-cheek it may be, a motherboard check would be ludicrous because you couldn't boot if it was missing, whereas you certainly can boot with a full or read-only drive.

code-disaster commented 2 years ago

perhaps LWJGL3 could use the libraries from the JAR instead of first copying them (what is this reason for this - faster access speeds?)

Because this is not how it works. You can't load a DLL from a resource, or from memory (*).

(*) I've seen attempts to try that, but I wouldn't be surprised if this leads to a whole new bunch of compatibility issues.

or simply give a warning if the user has less than, say, 10MB available on their C: drive or equivalent.

This reminds me of my idea that there is an open spot for a do some systems checks and yell at user for trying stupid things utility library. ;)

Frosty-J commented 2 years ago

That's interesting to see. Tommy suggested on Discord with a degree of uncertainty that LWJGL3 copies the DLLs but LWJGL2 doesn't, which adds up with LWJGL3 not working while LWJGL2 worked for this person. But if that's not how it works, I guess that rules that out.

Gamebuster19901 commented 2 years ago

I'm not sure if this is related, but I'm having intermittent issues with a similar stacktrace. I can usually run LibGDX programs fine, but sometimes I get a stacktrace similar to this every time I try to launch, and I will be unable to launch them until I restart my system.

---- WilderForge Crash Report----
//It compiles? Ship it.

Time: 2021-11-30T18:22:02.338644Z
Description: null
Stage: INIT

java.lang.NullPointerException
    at org.lwjgl.system.Checks.check(Checks.java:100)
    at org.lwjgl.glfw.GLFW.glfwGetFramebufferSize(GLFW.java:4831)
    at com.badlogic.gdx.backends.lwjgl3.NiceLwjgl3Application.createGlfwWindow(NiceLwjgl3Application.java:439)
    at com.badlogic.gdx.backends.lwjgl3.NiceLwjgl3Application.createWindow(NiceLwjgl3Application.java:377)
    at com.badlogic.gdx.backends.lwjgl3.NiceLwjgl3Application.createWindow(NiceLwjgl3Application.java:363)
    at com.badlogic.gdx.backends.lwjgl3.NiceLwjgl3Application.<init>(NiceLwjgl3Application.java:77)
    at com.worldwalkergames.legacy.LegacyDesktop.main(LegacyDesktop.java:117)
    at com.wildermods.wilderforge.launch.Main.launchGame(Main.java:70)
    at com.wildermods.wilderforge.launch.Main.main(Main.java:38)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at com.wildermods.wilderforge.launch.services.WilderLauncherService.lambda$0(WilderLauncherService.java:68)
    at cpw.mods.modlauncher.LaunchServiceHandlerDecorator.launch(LaunchServiceHandlerDecorator.java:37)
    at cpw.mods.modlauncher.LaunchServiceHandler.launch(LaunchServiceHandler.java:54)
    at cpw.mods.modlauncher.LaunchServiceHandler.launch(LaunchServiceHandler.java:72)
    at cpw.mods.modlauncher.Launcher.run(Launcher.java:82)
    at cpw.mods.modlauncher.Launcher.main(Launcher.java:66)
---- Additonal Information----

--System Details--
Wildermyth Version: 1.3+363 Dolse Ponder
Operating System: Linux
    Architecture: amd64
    Version: 5.13.0-21-generic
Cores: 24
Memory:
    Max heap size: 7.8 GiB
    Current heap size: 672.0 MiB
    Heap used: 28.8 MiB
    Free heap: 643.2 MiB
Java Version: OpenJDK Runtime Environment 11.0.12+7-Ubuntu-0ubuntu3 
    Vendor: Ubuntu
Uptime: PT3.814S

While I'm able to resolve my issue by simply restarting my computer, other people that have had similar issues were only able to resolve the issue after unplugging any additional monitors, and some people are unable to resolve the issue at all.

image image image

Also possibly relevant:

https://steamcommunity.com/app/979110/discussions/1/3006675644855488396/ https://www.reddit.com/r/wildermyth/comments/oqix8f/crash_on_launch/

tommyettinger commented 2 years ago

@Gamebuster19901 That's a similar error, but not the same -- both fail at line 100 of Checks.java, but get there through different failing sections of LWJGL3. I'd recommend starting a new issue, since yours seems to be affecting a release build of a well-tested game and you don't have the disk-space issue that seemed to be the cause initially. Actually, Rhapsodic's stacktrace in the shown Discord thread is the same as this issue, going through line 1127 of GLFW (monitor work area code), while you've hit a different one, going through line 4831 of GLFW (framebuffer code). Not sure what's happening... Your error doesn't seem to be directly related to this one, or at least what causes it. This could very legitimately be a bug in LWJGL3 (which is in the process of being updated to a newer version that should have lots of fixed bugs, we hope), or in GLFW, which LWJGL3 uses. WilderMyth would need to update to libGDX 1.10.1 whenever it gets released, which would almost certainly come with LWJGL 3.3.0, but even that might not fix an issue if it's in GLFW...

Since you're on Linux and your computer seems quite powerful (24 cores!), maybe running WilderMyth via some form of VM or Wine would be an option for you.

Gamebuster19901 commented 2 years ago

@tommyettinger I forgot to add that Rhapsodic was able to resolve their issue (which was the same as this one) by unplugging their second monitor.

image

Gamebuster19901 commented 2 years ago

@Gamebuster19901 That's a similar error, but not the same -- both fail at line 100 of Checks.java, but get there through different failing sections of LWJGL3. I'd recommend starting a new issue, since yours seems to be affecting a release build of a well-tested game and you don't have the disk-space issue that seemed to be the cause initially. Actually, Rhapsodic's stacktrace in the shown Discord thread is the same as this issue, going through line 1127 of GLFW (monitor work area code), while you've hit a different one, going through line 4831 of GLFW (framebuffer code). Not sure what's happening... Your error doesn't seem to be directly related to this one, or at least what causes it. This could very legitimately be a bug in LWJGL3 (which is in the process of being updated to a newer version that should have lots of fixed bugs, we hope), or in GLFW, which LWJGL3 uses. WilderMyth would need to update to libGDX 1.10.1 whenever it gets released, which would almost certainly come with LWJGL 3.3.0, but even that might not fix an issue if it's in GLFW...

Since you're on Linux and your computer seems quite powerful (24 cores!), maybe running WilderMyth via some form of VM or Wine would be an option for you.

My issue is indeed different. My OS will periodically update the graphics drivers. When it does so, OpenGL will not work until a system reboot.

>java -jar wildermyth.jar
0:00:089 4 LegacyDesktop VM ARGS: -server 
0:00:090 4 LegacyDesktop OS:  Linux
0:00:092 4 LegacyDesktop Wildermyth Version 1.5+392 Sunswallowers Wake Hotfix from patchline Steam
0:00:093 4 LegacyDesktop max memory is 8392802304
[LWJGL] GLFW_VERSION_UNAVAILABLE error
    Description : GLX: Failed to create context: BadValue (integer parameter out of range for operation)
    Stacktrace  :
        org.lwjgl.glfw.GLFW.nglfwCreateWindow(GLFW.java:1714)
        org.lwjgl.glfw.GLFW.glfwCreateWindow(GLFW.java:1897)
        com.badlogic.gdx.backends.lwjgl3.NiceLwjgl3Application.createGlfwWindow(NiceLwjgl3Application.java:433)
        com.badlogic.gdx.backends.lwjgl3.NiceLwjgl3Application.createWindow(NiceLwjgl3Application.java:377)
        com.badlogic.gdx.backends.lwjgl3.NiceLwjgl3Application.createWindow(NiceLwjgl3Application.java:363)
        com.badlogic.gdx.backends.lwjgl3.NiceLwjgl3Application.<init>(NiceLwjgl3Application.java:77)
        com.worldwalkergames.legacy.LegacyDesktop.main(LegacyDesktop.java:117)
0:00:193 4 LegacyDesktop Ran into an exception preventing Wildermyth from running. This specific exception (Checks.java:100) sometimes happens if you're using a laptop with an external monitor hooked up to it. Some players have been able to fix the issue by unplugging the external monitor, removing their monitors in Windows Device Manager and letting Windows reinstall them, or uninstalling their monitor adapter and downloading a new one.
0:02:334 5 LegacyDesktop exiting due to fatal runtime error java.lang.NullPointerException
    at org.lwjgl.system.Checks.check(Checks.java:100)
    at org.lwjgl.glfw.GLFW.glfwGetFramebufferSize(GLFW.java:4831)
    at com.badlogic.gdx.backends.lwjgl3.NiceLwjgl3Application.createGlfwWindow(NiceLwjgl3Application.java:439)
    at com.badlogic.gdx.backends.lwjgl3.NiceLwjgl3Application.createWindow(NiceLwjgl3Application.java:377)
    at com.badlogic.gdx.backends.lwjgl3.NiceLwjgl3Application.createWindow(NiceLwjgl3Application.java:363)
    at com.badlogic.gdx.backends.lwjgl3.NiceLwjgl3Application.<init>(NiceLwjgl3Application.java:77)
    at com.worldwalkergames.legacy.LegacyDesktop.main(LegacyDesktop.java:117)
>glxinfo
name of display: :1
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  151 (GLX)
  Minor opcode of failed request:  24 (X_GLXCreateNewContext)
  Value in failed request:  0x0
  Serial number of failed request:  110
  Current serial number in output stream:  111

History.log:

Start-Date: 2022-02-08  06:02:39
Commandline: /usr/bin/unattended-upgrade
Upgrade: bluez-cups:amd64 (5.60-0ubuntu2.1, 5.60-0ubuntu2.2)
End-Date: 2022-02-08  06:02:39

Start-Date: 2022-02-08  06:02:41
Commandline: /usr/bin/unattended-upgrade
Upgrade: libbluetooth-dev:amd64 (5.60-0ubuntu2.1, 5.60-0ubuntu2.2), libbluetooth3:amd64 (5.60-0ubuntu2.1, 5.60-0ubuntu2.2)
End-Date: 2022-02-08  06:02:41

Start-Date: 2022-02-08  06:02:43
Commandline: /usr/bin/unattended-upgrade
Upgrade: bluez-obexd:amd64 (5.60-0ubuntu2.1, 5.60-0ubuntu2.2)
End-Date: 2022-02-08  06:02:43

Start-Date: 2022-02-08  06:02:45
Commandline: /usr/bin/unattended-upgrade
Upgrade: bluez:amd64 (5.60-0ubuntu2.1, 5.60-0ubuntu2.2)
End-Date: 2022-02-08  06:02:47

Start-Date: 2022-02-09  06:39:05
Commandline: /usr/bin/unattended-upgrade
Install: libnvidia-egl-wayland1:amd64 (1:1.1.7-2build1, automatic)
Upgrade: libnvidia-fbc1-470:amd64 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), libnvidia-fbc1-470:i386 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), libnvidia-gl-470:amd64 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), libnvidia-gl-470:i386 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), libnvidia-extra-470:amd64 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), nvidia-compute-utils-470:amd64 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), nvidia-dkms-470:amd64 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), nvidia-driver-470:amd64 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), libnvidia-encode-470:amd64 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), libnvidia-encode-470:i386 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), nvidia-utils-470:amd64 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), xserver-xorg-video-nvidia-470:amd64 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), libnvidia-ifr1-470:amd64 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), libnvidia-ifr1-470:i386 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), libnvidia-decode-470:amd64 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), libnvidia-decode-470:i386 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), nvidia-kernel-common-470:amd64 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), libnvidia-cfg1-470:amd64 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), nvidia-kernel-source-470:amd64 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), libnvidia-compute-470:amd64 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1), libnvidia-compute-470:i386 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1)
End-Date: 2022-02-09  06:39:50

Start-Date: 2022-02-09  06:39:52
Commandline: /usr/bin/unattended-upgrade
Upgrade: libnvidia-common-470:amd64 (470.86-0ubuntu0.21.10.1, 470.103.01-0ubuntu0.21.10.1)
End-Date: 2022-02-09  06:39:52
tommyettinger commented 2 years ago

@Gamebuster19901 Hm, there's probably not much that can be done from the Wildermyth, the LWJGL or the libGDX side if the graphics drivers haven't fully loaded pending a restart. There might be some Linux service tricks you can do to get the graphics drivers reloaded on command, but I don't use Ubuntu, so your guess is as good as or better than mine.