How To Find Native Exception?

Started by gudenau, August 31, 2017, 02:07:04

Previous topic - Next topic

gudenau

I am currently porting an existing game engine over to LWJGL3 from LWJGL2 with a compatibility layer. (Don't ask)

Because of this I have a huge code base with lots of OGL calls and I do not know how to find the native call that causes the JVM to encounter an access violation. I tried to use the LWJGLX debug library, but that died when using
GL.createCapabilities();
which is odd to me. (Method not found if I recall)

Now, how to I find the native method that causes this so I can work back from it?

Native dump thing:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffdc09eef57, pid=3776, tid=0x0000000000000cf8
#
# JRE version: Java(TM) SE Runtime Environment (8.0_144-b01) (build 1.8.0_144-b01)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C  [lwjgl_opengl.dll+0xef57]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# D:\[REDACTED]\hs_err_pid3776.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.
#

Kai

The file D:\[REDACTED]\hs_err_pid3776.log contains the stack trace.

gudenau

Quote from: Kai on August 31, 2017, 07:28:07
The file D:\[REDACTED]\hs_err_pid3776.log contains the stack trace.

Oh, did not know that! Thanks a bundle for that pointer!

Now I know where it is that is causing the exception!

Now to figure out why glGetString is acting up, time to fire up the debugger.

gudenau

Quote from: gudenau on August 31, 2017, 16:38:27
Quote from: Kai on August 31, 2017, 07:28:07
The file D:\[REDACTED]\hs_err_pid3776.log contains the stack trace.

Oh, did not know that! Thanks a bundle for that pointer!

Now I know where it is that is causing the exception!

Now to figure out why glGetString is acting up, time to fire up the debugger.

How odd. I am creating second window for shared contexts and it is failing with GLFW_VERSION_UNAVAILABLE.

Code snippet:
glfwDefaultWindowHints();
glfwWindowHint(GLFW_VISIBLE, GLFW_FALSE);
long newWindow = glfwCreateWindow(1, 1, "SHAREDCONTEXT", NULL, oldWindow);


Where oldWindow is non-null, so the first call to glfwCreateWindow worked.

As far as I can tell GLFW_CONTEXT_VERSION_MAJOR and GLFW_CONTEXT_VERSION_MINOR are never used as well.

CoDi

Do you fully create the primary window, including glfwMakeContextCurrent() and GL.createCapabilities(), before creating this second window? Also, I'm not sure how closely windows need to match configuration, so try to glfwWindowHint() both of them the same way.

As a reference, this is how the libGDX backend creates windows with shared context.

Kai

Please read the documentation of glfwCreateWindow, especially the "Remarks" section:
QuoteWindows: The context to share resources with must not be current on any other thread.

Also, it'd be nice if you could shed some more light on what error you were getting with LWJGLX/debug.
For this, please follow these steps:
1. start with -javaagent:lwjglx-debug-1.0.0.jar=d;o=debug.log (note the =d;o=debug.log after the jar file name)
2. pipe stderr output to some "transform.log" file (or copy/paste from your IDE console)
3. attach the produced "debug.log" and "transform.log" files to a post here

gudenau

Quote from: CoDi on September 01, 2017, 07:03:20
Do you fully create the primary window, including glfwMakeContextCurrent() and GL.createCapabilities(), before creating this second window? Also, I'm not sure how closely windows need to match configuration, so try to glfwWindowHint() both of them the same way.

As a reference, this is how the libGDX backend creates windows with shared context.
Yeap, I do believe so.

Quote from: Kai on September 01, 2017, 07:12:34
Please read the documentation of glfwCreateWindow, especially the "Remarks" section:
QuoteWindows: The context to share resources with must not be current on any other thread.

Also, it'd be nice if you could shed some more light on what error you were getting with LWJGLX/debug.
For this, please follow these steps:
1. start with -javaagent:lwjglx-debug-1.0.0.jar=d;o=debug.log (note the =d;o=debug.log after the jar file name)
2. pipe stderr output to some "transform.log" file (or copy/paste from your IDE console)
3. attach the produced "debug.log" and "transform.log" files to a post here

I'll try this when I can

gudenau

Quote from: Kai on September 01, 2017, 07:12:34
Please read the documentation of glfwCreateWindow, especially the "Remarks" section:
QuoteWindows: The context to share resources with must not be current on any other thread.

Also, it'd be nice if you could shed some more light on what error you were getting with LWJGLX/debug.
For this, please follow these steps:
1. start with -javaagent:lwjglx-debug-1.0.0.jar=d;o=debug.log (note the =d;o=debug.log after the jar file name)
2. pipe stderr output to some "transform.log" file (or copy/paste from your IDE console)
3. attach the produced "debug.log" and "transform.log" files to a post here

java.lang.NoSuchMethodError: org.lwjglx.debug.opengl.GL.createCapabilities()Lorg/lwjgl/opengl/GLCapabilities;

The log does say this about my Display class, which causes that exception.
[debug] Modified [net/gudenau/lwjgl3/compatibility/opengl/Display] (8 calls into LWJGL)



Edit:
After making a quick wrapper to track thread usage with contexts, it seems that a thread does in fact have that context current. Now to figure out how to fix it.

Edit 2:
I got it to work, thanks a bundle!