Segfault on Windows

[scholza]

running the native application on windows (both compiled with GraalVM for Java 11 or Java 19) crashes with a segfault on the first invocation of lwjgl at GLFWErrorCallback.createPrint(System.err).set(); (or in glfwInit() if you remove the GLFWErrorCallback call)

Hello LWJGL 3.3.1 build 7!
[LWJGL] Version: 3.3.1 build 7
[LWJGL]          OS: Windows 10 v10.0
[LWJGL]         JRE: Windows amd64 11.0.18
[LWJGL]         JVM: Substrate VM vGraalVM 22.3.1 Java 11 CE by Oracle Corporation
[LWJGL] Loading JNI library: lwjgl
[LWJGL]         Module: org.lwjgl
[LWJGL]         Loaded from org.lwjgl.librarypath: <redacted>
[LWJGL] Loading library: glfw
[LWJGL]         Module: org.lwjgl.glfw

[ [ SubstrateSegfaultHandler caught a segfault in thread 0x000002014c05ec40 ] ]

...

Stacktrace for the failing thread 0x00000182a7f8b380:
  SP 0x0000006b98f3eed0 IP 0x00007ff860570549  IP is not within Java code. Trying frame anchor of last Java frame instead.
  SP 0x0000006b98f3ef00 IP 0x00007ff77a1de5e8  [image code] org.lwjgl.system.windows.WinBase.nGetModuleHandle(WinBase.java)
  SP 0x0000006b98f3ef60 IP 0x00007ff77a1ddae0  [image code] org.lwjgl.system.windows.WinBase.GetModuleHandle(WinBase.java:76)
  SP 0x0000006b98f3ef80 IP 0x00007ff77a1deb36  [image code] org.lwjgl.system.windows.WindowsLibrary.<clinit>(WindowsLibrary.java:25)
  SP 0x0000006b98f3efb0 IP 0x00007ff779bbac9b  [image code] com.oracle.svm.core.classinitialization.ClassInitializationInfo.invokeClassInitializer(ClassInitializationInfo.java:361)
  SP 0x0000006b98f3efc0 IP 0x00007ff779bb9c08  [image code] com.oracle.svm.core.classinitialization.ClassInitializationInfo.initialize(ClassInitializationInfo.java:277)
  SP 0x0000006b98f3f170 IP 0x00007ff77a18edb0  [image code] org.lwjgl.system.APIUtil.apiCreateLibrary(APIUtil.java:109)
  SP 0x0000006b98f3f190 IP 0x00007ff77a1a19ae  [image code] org.lwjgl.system.Library.loadNative(Library.java:363)
  SP 0x0000006b98f3f1e0 IP 0x00007ff77a1a1e5e  [image code] org.lwjgl.system.Library.loadNativeFromLibraryPath(Library.java:352)
  SP 0x0000006b98f3f1f0 IP 0x00007ff77a1a03f9  [image code] org.lwjgl.system.Library.loadNative(Library.java:266)
  SP 0x0000006b98f3f280 IP 0x00007ff77a108334  [image code] org.lwjgl.system.Library.loadNative(Library.java:224)
  SP 0x0000006b98f3f280 IP 0x00007ff77a108334  [image code] org.lwjgl.glfw.GLFW.<clinit>(GLFW.java:30)
  SP 0x0000006b98f3f2c0 IP 0x00007ff779bbac9b  [image code] com.oracle.svm.core.classinitialization.ClassInitializationInfo.invokeClassInitializer(ClassInitializationInfo.java:361)
  SP 0x0000006b98f3f2d0 IP 0x00007ff779bb9c08  [image code] com.oracle.svm.core.classinitialization.ClassInitializationInfo.initialize(ClassInitializationInfo.java:277)
  SP 0x0000006b98f3f480 IP 0x00007ff77a0db27e  [image code] java.lang.Class.ensureInitialized(DynamicHub.java:528)
  SP 0x0000006b98f3f480 IP 0x00007ff77a0db27e  [image code] jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:134)
  SP 0x0000006b98f3f480 IP 0x00007ff77a0db27e  [image code] jdk.internal.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:42)
  SP 0x0000006b98f3f4c0 IP 0x00007ff77a0d885d  [image code] jdk.internal.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:147)
  SP 0x0000006b98f3f4d0 IP 0x00007ff779e0c862  [image code] java.lang.reflect.Field.acquireFieldAccessor(Field.java:1169)
  SP 0x0000006b98f3f4f0 IP 0x00007ff779e0d171  [image code] java.lang.reflect.Field.getFieldAccessor(Field.java:138)
  SP 0x0000006b98f3f520 IP 0x00007ff77a18de6e  [image code] java.lang.reflect.Field.getInt(Field.java:612)
  SP 0x0000006b98f3f520 IP 0x00007ff77a18de6e  [image code] org.lwjgl.system.APIUtil.apiClassTokens(APIUtil.java:350)
  SP 0x0000006b98f3f5a0 IP 0x00007ff77a10a423  [image code] org.lwjgl.glfw.GLFWErrorCallback$1.<init>(GLFWErrorCallback.java:98)
  SP 0x0000006b98f3f5c0 IP 0x00007ff779ba1217  [image code] org.lwjgl.glfw.GLFWErrorCallback.createPrint(GLFWErrorCallback.java:97)
  SP 0x0000006b98f3f5c0 IP 0x00007ff779ba1217  [image code] com.github.chirontt.lwjgl.demo.HelloWorld.init(HelloWorld.java:46)
  SP 0x0000006b98f3f630 IP 0x00007ff779ba2bda  [image code] com.github.chirontt.lwjgl.demo.HelloWorld.run(HelloWorld.java:28)
  SP 0x0000006b98f3f670 IP 0x00007ff779baeb81  [image code] com.github.chirontt.lwjgl.demo.HelloWorld.main(HelloWorld.java:125)
  SP 0x0000006b98f3f670 IP 0x00007ff779baeb81  [image code] com.oracle.svm.core.JavaMainWrapper.runCore0(JavaMainWrapper.java:175)
  SP 0x0000006b98f3f6a0 IP 0x00007ff779bae7f3  [image code] com.oracle.svm.core.JavaMainWrapper.runCore(JavaMainWrapper.java:135)
  SP 0x0000006b98f3f6a0 IP 0x00007ff779bae7f3  [image code] com.oracle.svm.core.JavaMainWrapper.doRun(JavaMainWrapper.java:232)
  SP 0x0000006b98f3f6e0 IP 0x00007ff779be84c6  [image code] com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:218)
  SP 0x0000006b98f3f6e0 IP 0x00007ff779be84c6  [image code] com.oracle.svm.core.code.IsolateEnterStub.JavaMainWrapper_run_3148eece06270530b6e0d4d60311411342c82698(IsolateEnterStub.java:0)

...

Any ideas how to fix this? Or is this expected? I found oracle/graal#5815 which suggests that it is expected to not work?

[chirontt]

This problem has existed since GraalVM 21.x version. But for Windows native image generated by GraalVM 21.x, for this project there is a workaround:

• checkout a previous commit suitable for GraalVM 21.x version, like this 75bab416 commit where the project just got upgraded to LWJGL 3.3.1
• after the creation of the native image (which would crash at startup as reported in this issue), compress the image with the UPX compression tool with a command like upx --best <image name>.exe
• run the compressed image file; it should work without problem.

But then, when you move to GraalVM 22.x version, the compressed image by UPX no longer works - it starts up and then aborts with nothing shown on screen. This problem is reported in oracle/graal#4340. Yet there is a workaround for it: follow this comment to 'fix' the svm.jar of your GraalVM 22.x installation and re-generate the native image, the compressed image would work again.

But alas, when you move to GraalVM 22.3.x version, the above hack fails to work, and people are trying to find another hack again, but I'm not aware of any.

Moral of the story: for this project, stick with GraalVM 21.x version (at least in Windows), and with the UPX tool.

[scholza]

Thanks a lot!