EXCEPTION_ACCESS_VIOLATION at GLFW.glfwDestroyWindow()

[awesomelemonade]

Hello, awesomelemonade here..

I'm having a problem where GLFW.glfwDestroyWindow(window) would sometimes produce the following error:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x58d46d12, pid=6436, tid=6004
#
# JRE version: Java(TM) SE Runtime Environment (7.0_67-b01) (build 1.7.0_67-b01)
# Java VM: Java HotSpot(TM) Client VM (24.65-b04 mixed mode windows-x86 )
# Problematic frame:
# C  [lwjgl.dll+0x6d12]
#
# 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:
# G:\Game_Engine\3D_Game_Engine\hs_err_pid6436.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

G:\Game_Engine\3D_Game_Engine/hs_err_pid6436.log produces a really long piece of text. The message would exceed maximum allowed length (20000 characters), so I didn't post it. I will post it in parts if absolutely needed.

Although it does not seem to affect my program, I'm curious on why this happens..

Thanks in advance,
-lemon

[spasi]

Hey awesomelemonade,

The forum software supports adding files to posts as attachments. Click on "Attachments and other options" in the post form.

I'm interested in seeing the full log, but some other details would also be helpful. Is there anything interesting in the output if you run your program with -Dorg.lwjgl.util.Debug=true? You mentioned that the crash happens only sometimes, have you been able to figure out the exact circumstances? Could you maybe post a small test program that has the same behavior?

[awesomelemonade]

Alrighty, well I narrowed down it pretty far, it seems like it would just crash there and not run anything else that happens after it (In that thread).

Here is the full crash log, I commented out line 933 because it includes my username (which is my real name)

How do you test with -Dorg.lwjgl.util.Debug=true? Is that the arguments to pass through the main method?

[spasi]

How do you test with -Dorg.lwjgl.util.Debug=true? Is that the arguments to pass through the main method?

It's a JVM parameter, you use it when launching your program.

I get a similar crash if I try to destroy a window that has already been destroyed. Could you please check if there's such a bug in your code?

[awesomelemonade]

I printed a message before I destroyed the window in my GuiUtil which is basically a wrapper that calls all the glfw methods. It seems to only print once when the error occurs.

So I also just tested with the JVM Argument you gave me, and this is what it says (Besides the error I showed you before)

[LWJGL] Version 3.0.0a | Windows 7 | x86
[LWJGL] MemoryUtil MemoryAccessor: MemoryAccessorUnsafe

[awesomelemonade]

Sorry for the Double Post:

I'm trying it on a separate computer, but what it says by LWJGL should remain the same as I use Version 3.0.0a, Windows 7, and x86 for both computers.

This is also tested on the current Nightly Build #19

[spasi]

Another thing you could try is not call glfwDestroyWindow() at all. glfwTerminate() will destroy all open windows. Does it still crash?

I'd be grateful if you could isolate some example code that exhibits the same crash. Something that doesn't use any of your libraries, just plain LWJGL calls.

[awesomelemonade]

I only use LWJGL calls, (that includes GLFW right?) with no libraries...

I will try without glfwdestroywindow.. I'll report back.

[awesomelemonade]

I may have got it, because you are passing in a "long", I don't think you should be able to have a negative number.

We may have accidentally made the window variable a negative number...

Please Confirm,
Thanks

[spasi]

I only use LWJGL calls, (that includes GLFW right?) with no libraries...

I meant, the example should be a simple class with a main method, init code, the rendering loop, exit code.

I may have got it, because you are passing in a "long", I don't think you should be able to have a negative number.

We may have accidentally made the window variable a negative number...

Two's complement integers have been designed to have bit compatible signed and unsigned representations. This means that if you have an unsigned integer (e.g. an opaque pointer, like GLFWwindow), cast it to signed integer, then cast it back to unsigned, you'll get the exact same number. This is why LWJGL uses long for pointer values and it's safe to pass them in and out of native methods.

Implementation note: LWJGL's generated code can be found in this repo. The casts from and to pointer values happen in native code, see this for example.

[awesomelemonade]

Hi, I'm currently experiencing more EXCEPTION_ACCESS_VIOLATION...

And, it's at the time where I close the window. I'm using Build #37, and the code is here..

https://bitbucket.org/awesomelemonade/game-engine

I recently restarted lots of my code, so lots of the classes aren't being used.

[spasi]

Hey awesomelemonade,

I tried your code and I must say you're doing horrible things with threads and reflection. I really do not mean any offence, it's just my honest opinion that you should take a step back and write clean, single threaded code. If and when your code becomes complex enough, then you can consider a more clever architecture, preferably with use of reliable 3rd party libraries/frameworks.

The crash itself is simple to explain. You're starting a thread before your main loop that does updateTimer.sync(60), which eventually calls glfwGetTime(). This thread is in no way synchronized with the main thread, so when you try to exit the program, the secondary thread keeps running. GLFW has been terminated and on the next call to glfwGetTime() an error is raised. But you have also released the error callback! GLFW still knows about the old callback address, tries to call it and you get the EXCEPTION_ACCESS_VIOLATION.

Comment out errorCallback.release() in the close() method and see what happens.

[awesomelemonade]

Ah, I see....

Is there any reason why it should be single threaded? I've been wanting to try multithreading...

You mentioned reliable 3rd party libraries/frameworks... do you suggest any of them..?

Thanks for the help!

[awesomelemonade]

Alright, well, I fixed it, but I'm still looking for your input on my code... Is there any specific guidelines?

Thanks in advanced

[Cornix]

Is there any reason why it should be single threaded?

OpenGL is by nature single threaded, its not supposed to be used with multiple threads. The OpenGL context is owned by a single thread and all openGL calls must be made by the Thread that owns the context. You can use multithreading by sharing the ownership of the context but this is expensive and will probably give you worse performance.