Lwjgl3: JVM Crash while resizing a window (GLFW)

[voidburn]

Reproduced on:

OS: Win 10 Pro 64bit (10.0.14393)
Intel Core i7-6700k @ 4.00Ghz

Video hardware Nvidia GTX 980ti
Video driver Nvidia: 375.70 & 375.95

Video hardware Intel: Intel HD Graphics 530
Video driver Intel: 20.19.15.4463

Unable to reproduce on:

OS: Win 10 Pro 64bit (10.0.14393) / Linux Ubuntu 16.04 latest
Intel Core i5-3570k @ 3.80Ghz
Integrated GPU
GTX 760, drivers 375.95

OS: Win 7 Ultimate 64bit
Intel Core duo E6600
Nvidia GTX 760, drivers 375.95

OS: Win 10 Pro 64bit (10.0.14393)
AMD A8-6800 APU
Integrated GPU, latest crimson drivers

OS: Win 10 Pro 64bit (10.0.14393) / Linux Ubuntu 16.04 latest
Intel Core i7-5820k
GTX 970, drivers 375.95

How to reproduce:
Launch the demo: https://github.com/LWJGL/lwjgl3-demos/blob/master/src/org/lwjgl/demo/opengl/glfw/Multithreaded.java

Grab a corner (not an edge, it crashes specifically when resizing both width and height) and start resizing. The crash is random, but usually can be triggered in less than a second with a circular and vigorous "rub" :)

Sadly I can't get it to create a dump, but I'm fairly certain that the buffers swap is the culprit here, since this is the only demo in which polling events doesn't stop the render loop.

Discovered since it currently affects the lwjgl3 backend in Libgdx 1.9.5-SNAPSHOT

Reproducible in GLFW 3.2.1
Run the splitview example, execute resizes as above -> Segfault

[Spasi]

Cannot reproduce on Windows 10 x64, Nvidia GTX 970, driver v375.95. A crash dump would be helpful.

[voidburn]

Here's some more data:

Crash in my own application (I still cannot get a dump reliably) that I got yesterday. For all intents and purposes all calls in UnobtaniumGL* classes can be considere the equivalent of libgdx's Lwjgl3 backend in their current snapshot, while working on some backend fixes I simply duplicated the code so I had the reference base always at hand while making changes: http://pastebin.com/3AMArDQ2

Related libgdx issue, describing how I avoid the crash by commenting the buffer swap: https://github.com/libgdx/libgdx/issues/4434

Other notes: the resize triggers almost exclusively when the resize motion is circular, resizing from the corner in or out in a straight line does not trigger the issue.

[voidburn]

Tested out with the 375.95 drivers, still get it, also lucked out and got a crash dump with the multithreaded demo! See attachment.

hs_err_pid1372.zip

[voidburn]

Probably unhelpful, but I also captured the screen while generating the dump above
2016-11-23 12-47-48.zip

[voidburn]

I swear, I don't enjoy crashing it (I secretly might..) but while I was bashing it hard I randomly got this console message during a crash, maybe unrelated, but I thought it could provide some additional clues maybe..

If needed, I have a minidump as well, but it's 55MB compressed, I can provide on request.

[LWJGL] OpenGL debug message
ID: 0x501
Source: API
Type: ERROR
Severity: HIGH
Message: GL_INVALID_VALUE error generated. Invalid texture format.

[httpdigest]

Does it happen with native GLFW applications, too?
I prepared a simple test which in essence does the same as the lwjgl3-demos Multithreaded application. (except it just swaps buffers)
64-bit Win32 exe download here (statically linked against msvc 2015 runtime): https://www.dropbox.com/s/4nvducku9moxqbx/glfwtest.exe?dl=1
Source code: https://www.dropbox.com/s/9rda5rkiehucpay/main.c?dl=1

[Spasi]

I can see how the libgdx and unobtanium implementations could have an issue. There are OpenGL function calls inside the framebuffer size callback handler, which is asking for trouble if the OpenGL context is current in a different thread from the event loop.

I can't see how Multithreaded in lwjgl3-demos could be suffering from the same issue. The width/height updates are not properly synchronized, but I don't think problems there could bring the driver down.

A couple more things you could try:

• Run the demo from the command line instead of IDEA.
• Try setting Threaded optimization in the Nvidia Control Panel to On or Off.

[voidburn]

@httpdigest Yes! Crashed exactly like the lwjgl3 demo.

Trying building and running from command line and then disabling the threaded optimization.

[voidburn]

@Spasi Regarding the implementations: I'm rewriting the backend on my own because I'm not sure if I can keep the multi-window feature AND multithread the render loop, but the latter is more important to me, thanks for the heads-up, I'll definitely make sure to get rid of those.

[voidburn]

@Spasi Built an artifact and ran via command line: crashed as usual. Also crashed when the global Threaded optimization in the drivers was set to Off (It was defaulting to Auto).

Attaching the built executable jar (entry point is the multithreaded demo) and the crash dump.
lwjgl3_demos_jar.zip

[voidburn]

I can reproduce it with the integrated GPU as well, I guess it's not an Nvidia driver issue. Updated hardware info including the cpu I'm using and tested with.

[sormuras]

Can not reproduce with the executable jar linked in https://github.com/LWJGL/lwjgl3/issues/254#issuecomment-262536401 -- all resizing works.

[voidburn]

It's proving extremely hard to reproduce outside this machine, I've tested 5 different PCs and 3 different OSs so far, it only affects this one. If someone by any chance happens to have the same issue I'd love to take note of the hardware and os involved.

[voidburn]

Well well, inspired by the uniqueness of this I started looking into other running processes in my system and excluding them one by one.

Turns out that what was interfering with GLFW was Asus's Sonic Suite, which was reinstalled automatically with the latest driver updates. Somehow that thing hooks itself into everything (Autoruns.exe and Procmon.exe would crash immediately).

So sad that the first thing I noticed this problem with was my own project.

Glad I can close this and leave it up for future reference, in case someone ends up into the same goose chase as I did.