EGL VM Crashes

[smith]

After having so many issues with GLFW + Swing/AWT I thought I would try using EGL and OpenGLES, however this just crashes the VM immediately on EGL.create(). Does EGL require GLFW?

---------------  T H R E A D  ---------------

Current thread (0x00007fbbd0012000):  JavaThread "main" [_thread_in_native, id=9906, stack(0x00007fbbd6b4b000,0x00007fbbd6c4c000)]

Stack: [0x00007fbbd6b4b000,0x00007fbbd6c4c000],  sp=0x00007fbbd6c49f28,  free space=1019k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x00007fbbd032c271
j  org.lwjgl.egl.EGL$1.getFunctionAddress(Ljava/nio/ByteBuffer;)J+8
j  org.lwjgl.system.FunctionProvider.getFunctionAddress(Ljava/lang/CharSequence;)J+12
j  org.lwjgl.egl.EGL.createClientCapabilities()Lorg/lwjgl/egl/EGLCapabilities;+31
j  org.lwjgl.egl.EGL.create(Lorg/lwjgl/system/FunctionProvider;)V+20
j  org.lwjgl.egl.EGL.create(Lorg/lwjgl/system/SharedLibrary;)V+8
j  org.lwjgl.egl.EGL.create()V+113
j  org.lwjgl.egl.EGL.<clinit>()V+19
v  ~StubRoutines::call_stub
V  [libjvm.so+0x83cd09]
V  [libjvm.so+0x81acad]
V  [libjvm.so+0x81b07e]
V  [libjvm.so+0xa0999d]
V  [libjvm.so+0xa0cd6b]
V  [libjvm.so+0x8372d6]
V  [libjvm.so+0x837875]
j  gltest.GLTest.main([Ljava/lang/String;)V+0
v  ~StubRoutines::call_stub
V  [libjvm.so+0x83cd09]
V  [libjvm.so+0x8b6d34]
V  [libjvm.so+0x8b9681]
C  [libjli.so+0x548e]
C  [libjli.so+0x950d]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.lwjgl.system.JNI.callPP(JJ)J+0
j  org.lwjgl.egl.EGL$1.getFunctionAddress(Ljava/nio/ByteBuffer;)J+8
j  org.lwjgl.system.FunctionProvider.getFunctionAddress(Ljava/lang/CharSequence;)J+12
j  org.lwjgl.egl.EGL.createClientCapabilities()Lorg/lwjgl/egl/EGLCapabilities;+31
j  org.lwjgl.egl.EGL.create(Lorg/lwjgl/system/FunctionProvider;)V+20
j  org.lwjgl.egl.EGL.create(Lorg/lwjgl/system/SharedLibrary;)V+8
j  org.lwjgl.egl.EGL.create()V+113
j  org.lwjgl.egl.EGL.<clinit>()V+19
v  ~StubRoutines::call_stub
j  gltest.GLTest.main([Ljava/lang/String;)V+0
v  ~StubRoutines::call_stub

siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x00007fbbd032c271

[spasi]

This is a bug in 3.2.2 and it will be fixed in the next 3.2.3 snapshot (build 3). You could try with 3.2.1 until then.

Thanks for reporting!

[smith]

3.2.1 works fine, thanks for the quick response!

[smith]

I tried Snapshot 3 and it works fine on Linux but I'm getting a crash on Windows. I think the same crash happens with 3.2.1 so it might be an issue with my version of libEGL.dll (I just grabbed the one from Chrome),

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000000000000, pid=23100, tid=16920
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C  0x0000000000000000
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  S U M M A R Y ------------

Command Line: -agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:59026 -Djava.library.path=C:\Users\ssmith2\Dropbox\workspace\GLTest\lib\natives -javaagent:C:\Users\ssmith2\eclipse\java-2018-09\eclipse\configuration\org.eclipse.osgi\533\0\.cp\lib\javaagent-shaded.jar -Dfile.encoding=Cp1252 gltest.GLTest

Host: Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz, 12 cores, 15G,  Windows 10 , 64 bit Build 17134 (10.0.17134.706)
Time: Sun May 26 08:14:45 2019 Hawaiian Standard Time elapsed time: 72 seconds (0d 0h 1m 12s)

---------------  T H R E A D  ---------------

Current thread (0x00000227efcd1800):  JavaThread "main" [_thread_in_native, id=16920, stack(0x0000005052c00000,0x0000005052d00000)]

Stack: [0x0000005052c00000,0x0000005052d00000],  sp=0x0000005052cfe7f8,  free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.lwjgl.system.JNI.callPP(JJ)J+0
j  org.lwjgl.egl.EGL$1.getFunctionAddress(Ljava/nio/ByteBuffer;)J+8
j  org.lwjgl.system.FunctionProvider.getFunctionAddress(Ljava/lang/CharSequence;)J+12
j  org.lwjgl.egl.EGL.createClientCapabilities()Lorg/lwjgl/egl/EGLCapabilities;+31
j  org.lwjgl.egl.EGL.create(Lorg/lwjgl/system/FunctionProvider;)V+20
j  org.lwjgl.egl.EGL.create(Lorg/lwjgl/system/SharedLibrary;)V+8
j  org.lwjgl.egl.EGL.create()V+113
j  org.lwjgl.egl.EGL.<clinit>()V+19
v  ~StubRoutines::call_stub
j  org.lwjgl.egl.EGL10.eglGetDisplay(J)J+0
j  gltest.GLTest.main([Ljava/lang/String;)V+1
v  ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), data execution prevention violation at address 0x0000000000000000

[spasi]

Not sure why that happens (with the same error even). Could you step into EGL.createClientCapabilities with a debugger to see where it crashes exactly?

[smith]

It's in the callPP function fom EGL.java:95 looking for function "eglQueryString".

[smith]

I found a fix, it was not happy with the library path being set so I just explicitly loaded libEGL.dll and then it worked fine.

[spasi]

Could you please run the program with -Dorg.lwjgl.util.Debug=true -Dorg.lwjgl.util.DebugLoader=true, with and without the workaround? What is the difference between the two?

[smith]

With Hack:

[LWJGL] Version: 3.2.3 build 3
[LWJGL] 	 OS: Windows 10 v10.0
[LWJGL] 	JRE: 11.0.1 amd64
[LWJGL] 	JVM: OpenJDK 64-Bit Server VM v11.0.1+13 by Oracle Corporation
[LWJGL] Loading library (system): lwjgl
[LWJGL] 	Using SharedLibraryLoader...
[LWJGL] 	Found at: C:\Users\ssmith2\AppData\Local\Temp\lwjglssmith2\3.2.3-build-3\lwjgl.dll
[LWJGL] 	Found at: C:\Users\ssmith2\AppData\Local\Temp\lwjglssmith2\3.2.3-build-3\lwjgl.dll
[LWJGL] 	Loaded from org.lwjgl.librarypath: C:\Users\ssmith2\AppData\Local\Temp\lwjglssmith2\3.2.3-build-3\lwjgl.dll
[LWJGL] Loading library: libEGL
[LWJGL] 	libEGL.dll not found in org.lwjgl.librarypath=C:\Users\ssmith2\AppData\Local\Temp\lwjglssmith2\3.2.3-build-3
[LWJGL] 	Loaded from system paths: C:\Users\ssmith2\Dropbox\workspace\Machina\libs\natives\libEGL.dll
[LWJGL] Java 10 multiplyHigh enabled
[LWJGL] Java 9 check intrinsics enabled
[LWJGL] Loading library (system): lwjgl_opengles
[LWJGL] 	Using SharedLibraryLoader...
[LWJGL] 	Found at: C:\Users\ssmith2\AppData\Local\Temp\lwjglssmith2\3.2.3-build-3\lwjgl_opengles.dll
[LWJGL] 	Loaded from org.lwjgl.librarypath: C:\Users\ssmith2\AppData\Local\Temp\lwjglssmith2\3.2.3-build-3\lwjgl_opengles.dll
[LWJGL] Loading library: libGLESv2
[LWJGL] 	libGLESv2.dll not found in org.lwjgl.librarypath=C:\Users\ssmith2\AppData\Local\Temp\lwjglssmith2\3.2.3-build-3
[LWJGL] 	Loaded from system paths: C:\Users\ssmith2\Dropbox\workspace\Machina\libs\natives\libGLESv2.dll
[LWJGL] Warning: Failed to instantiate memory allocator: org.lwjgl.system.jemalloc.JEmallocAllocator. Using the system default.
[LWJGL] MemoryUtil allocator: StdlibAllocator
[LWJGL] Java 10 memcpy enabled

Without Hack:

[LWJGL] Version: 3.2.3 build 3
[LWJGL] 	 OS: Windows 10 v10.0
[LWJGL] 	JRE: 11.0.1 amd64
[LWJGL] 	JVM: OpenJDK 64-Bit Server VM v11.0.1+13 by Oracle Corporation
[LWJGL] Loading library (system): lwjgl
[LWJGL] 	Using SharedLibraryLoader...
[LWJGL] 	Found at: C:\Users\ssmith2\AppData\Local\Temp\lwjglssmith2\3.2.3-build-3\lwjgl.dll
[LWJGL] 	Found at: C:\Users\ssmith2\AppData\Local\Temp\lwjglssmith2\3.2.3-build-3\lwjgl.dll
[LWJGL] 	Loaded from org.lwjgl.librarypath: C:\Users\ssmith2\AppData\Local\Temp\lwjglssmith2\3.2.3-build-3\lwjgl.dll
[LWJGL] Loading library: libEGL
[LWJGL] 	libEGL.dll not found in org.lwjgl.librarypath=C:\Users\ssmith2\AppData\Local\Temp\lwjglssmith2\3.2.3-build-3
[LWJGL] 	libEGL.dll not found in system paths
[LWJGL] 	Loaded from java.library.path: C:\Users\ssmith2\Dropbox\workspace\Machina\libs\natives\libEGL.dll
Error loading EGL entry points.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000000000000, pid=22604, tid=24824
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C  0x0000000000000000
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\ssmith2\Dropbox\workspace\Machina\hs_err_pid22604.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

[smith]

As another data point, I tried adding the folder with the dll's to the classpath rather than java.library.path and got:

[LWJGL] Version: 3.2.3 build 3
[LWJGL] 	 OS: Windows 10 v10.0
[LWJGL] 	JRE: 11.0.1 amd64
[LWJGL] 	JVM: OpenJDK 64-Bit Server VM v11.0.1+13 by Oracle Corporation
[LWJGL] Loading library (system): lwjgl
[LWJGL] 	Using SharedLibraryLoader...
[LWJGL] 	Found at: C:\Users\ssmith2\AppData\Local\Temp\lwjglssmith2\3.2.3-build-3\lwjgl.dll
[LWJGL] 	Found at: C:\Users\ssmith2\AppData\Local\Temp\lwjglssmith2\3.2.3-build-3\lwjgl.dll
[LWJGL] 	Loaded from org.lwjgl.librarypath: C:\Users\ssmith2\AppData\Local\Temp\lwjglssmith2\3.2.3-build-3\lwjgl.dll
[LWJGL] Loading library: libEGL
[LWJGL] 	Using SharedLibraryLoader...
[LWJGL]     Extracting: /C:/Users/ssmith2/Dropbox/workspace/Machina/libs/natives/libEGL.dll
[LWJGL] 	Loaded from org.lwjgl.librarypath: C:\Users\ssmith2\AppData\Local\Temp\lwjglssmith2\3.2.3-build-3\libEGL.dll
Error loading EGL entry points.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000000000000, pid=7588, tid=12160
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C  0x0000000000000000
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\ssmith2\Dropbox\workspace\Machina\hs_err_pid7588.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

[spasi]

What is the exact workaround you use? How do you load libEGL.dll explicitly when it works? Also, did you also have to copy libGLESv2.dll in the same folder for it to work?

[smith]

I do this first thing in main:

    		System.load(new File("./libs/natives/libGLESv2.dll").getAbsolutePath());
    		System.load(new File("./libs/natives/libEGL.dll").getAbsolutePath());

[spasi]

Thanks, reproduced. It's the first line that actually does the trick. It looks like the libEGL.dll that Chrome ships is implicitly linked with libGLESv2.dll. When libEGL.dll is loaded, Windows tries to resolve libGLESv2.dll automatically, but it doesn't know anything about Java's library path. The missing functions cannot be found anywhere else so the process crashes. By loading libGLESv2.dll explicitly before libEGL.dll, the functions are already available and linkage is successful.

This is not standard behavior of course and a normal EGL implementation wouldn't have such a dependency (it doesn't make much sense either, you first create a context with EGL and then use OpenGL ES with that context). However, this is an implementation that is private to Chrome and there's probably a useful reason it works like that. It's just not meant to be used outside Chrome.

If you don't have another EGL/GLES implementation available, here are a few other workarounds that should work, without messing with System.load (meant for JNI libraries):

- Put the two dlls in the application's working directory.
- Add ./libs/natives to the PATH environment variable.
- Initialize the GLES bindings before EGL. Calling GLES.getFunctionProvider() should be enough. (recommended)

For more information: Dynamic-Link Library Search Order

[smith]

Thanks for looking into this. I moved the dll's to the working directory which works fine and seems to be what everyone does when bundling EGL/GLES with an application. I think pretty much all implementations are based on ANGLE so I wonder if it would be useful to include it as an optional LWJGL bundle. I did have one final question, why does the VM crash rather than the usual unsatisfied link exception?

[spasi]

When implicit linkage fails, Windows terminates the process instead of LoadLibrary returning NULL and producing an error. So the JVM doesn't have a chance to recover.