Hello Guest

How To Find Native Exception?

  • 7 Replies
  • 5770 Views
How To Find Native Exception?
« on: August 31, 2017, 02:07:04 »
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
Code: [Select]
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:
Code: [Select]
#
# 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.
#
« Last Edit: August 31, 2017, 16:38:39 by gudenau »

*

Kai

Re: How To Find Native Exception
« Reply #1 on: August 31, 2017, 07:28:07 »
The file D:\[REDACTED]\hs_err_pid3776.log contains the stack trace.

Re: How To Find Native Exception
« Reply #2 on: August 31, 2017, 16:38:27 »
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.

Re: How To Find Native Exception
« Reply #3 on: August 31, 2017, 18:09:31 »
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:
Code: [Select]
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.

*

Offline CoDi

  • *
  • 49
Re: How To Find Native Exception?
« Reply #4 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.

*

Kai

Re: How To Find Native Exception?
« Reply #5 on: September 01, 2017, 07:12:34 »
Please read the documentation of glfwCreateWindow, especially the "Remarks" section:
Quote
Windows: 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
« Last Edit: September 01, 2017, 10:52:27 by Kai »

Re: How To Find Native Exception?
« Reply #6 on: September 02, 2017, 00:13:26 »
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.

Please read the documentation of glfwCreateWindow, especially the "Remarks" section:
Quote
Windows: 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

Re: How To Find Native Exception?
« Reply #7 on: September 03, 2017, 01:38:25 »
Please read the documentation of glfwCreateWindow, especially the "Remarks" section:
Quote
Windows: 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

Code: [Select]
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.
Code: [Select]
[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!
« Last Edit: September 03, 2017, 01:50:19 by gudenau »