Yes, I'm using minimal LWJGL - core, GL, AL, GLFW only at this stage.
Nothing fancy is going on regarding strings. Quite often it doesn't even get as far as loading source code to the shaders as it crashes before it even gets a window up.
There's only one context, and usually when it crashes, still only one thread doing any work (tried singlethreaded too, same results).
In short there was no combination of things I did or disabled or properties set that fixed it other than simply trying 3.1.6, when everything worked exactly perfectly, first time (sound included).
I need to do a bit more work to get the project to build properly (getting theagentd to try running it from Eclipse was a bit of an eye-opener as to how much of a faff that was) but then I can easily deploy it to Steam for you. Getting to the bottom of this would seem to be of extreme importance because it does rather look like right now the entire 3.2.x is totally broken and has been for a while!

Cas

I need to do a bit more work to get the project to build properly (getting theagentd to try running it from Eclipse was a bit of an eye-opener as to how much of a faff that was) but then I can easily deploy it to Steam for you. Getting to the bottom of this would seem to be of extreme importance because it does rather look like right now the entire 3.2.x is totally broken and has been for a while!

That's great, thank you. Obviously, I'll be deeply disheartened if this turns out to be a bug in LWJGL. It would mean the testing I perform is lacking and I can't depend on the community to promptly discover and report such issues.

One more thing you could try: LWJGLX/debug (direct download: https://build.lwjgl.org/addons/lwjglx-debug/lwjglx-debug-1.0.0.jar). Run with:

java -javaagent:lwjglx-debug-1.0.0.jar <...normal arguments..>
Assuming no obvious error pops up until it crashes, you can enable tracing with:

java -javaagent:lwjglx-debug-1.0.0.jar=t;o=trace.log <...normal arguments..>
Review the log (to remove sensitive information if necessary) and attach it here or in a PM. KaiHH was kind enough to do a couple of fixes earlier, the trace will now include all LWJGL calls. This will help me focus the investigation to what's actually being used only.

Obviously, I'll be deeply disheartened if this turns out to be a bug in LWJGL. It would mean the testing I perform is lacking and I can't depend on the community to promptly discover and report such issues.

Just dropping in to note that we are running Pathway builds on LWJGL 3.2.0 (with a modified libGDX 1.9.9) since half a year now, and I didn't hear of such trouble. Between our dev team, external contributors and our publisher, this has been running on quite a number of systems already, so I would be surprised if this is a widespread problem.

I don't know if it helps, but here's my OpenAL setup code:
https://gist.github.com/code-disaster/a14993f38966ba06fa4f579820f89d43

I noted a couple of things:
- my call order (device, context) is slightly different to yours
- I run audio on a separate thread, so there are thread context calls
- that retry loop is because we've had a problem on some systems that device creation would fail on the first try, but succeed after a short delay

It isn't the AL library that's the problem it turns out though, that actually works perfectly well on 3.1.6 (and removing AL from the game didn't fix it in 3.2.x).
It very much looks like the problem the Minecraft guys were running in to in the thread Spasi linked to back up the thread.
As to why it "seems" ok... this is the peril of native code - it probably isn't, you've just been lucky enough that whatever memory corruption is occurring hasn't blown up for enough users that they've started complaining at you yet You'd be surprised how gamers are conditioned to just accept crash bugs and shrug and restart from the world of AAA...

I'm slowly working towards getting a build together but I'm a bit busy working for The Man right now and other things.

Cas

It very much looks like the problem the Minecraft guys were running in to in the thread Spasi linked to back up the thread.

They're having crashes with 3.1.6 too though. Also:

It seems to be exclusive to development type environments, where the game is launched from either an IDE or gradle.

The peculiar thing about running from an IDE is that if you do look at the actual process that the IDE spawns, and its commandline, there's absolutely nothing different to how it looks than if it were launched from a command prompt. So again... possibly just random luck here.

Cas

It occurs to me that it might be GLFW that's the problem but that'll be harder to test.

Cas

OH NOES!!!!11!!!

It's just randomly started to go wrong with LWJGL 3.1.6 now too No reason for it... was working last time I tried. Now it's not.

Cas

Any news regarding this issue?

The news was, it was "my fault", except that the LWJGL API makes it a) very easy to get wrong b) doesn't check and c) gives you all the fun of C memory corruption and everything that entails. Personally I don't think it's a great way to do things but I've fixed it and moved on.
The bigger picture is that there are so many ways to get this wrong in the whole of the LWJGL API surface that there's no way anyone sane would condone its use, but LWJGL is what it is and nobody's about to change it.

Cas

I'd really be interested in the actual specifics of the usage error. I am trying to further the development of the LWJGL 3 "validation layer" project: https://github.com/LWJGLX/debug and for that, feedback from actual projects is invaluable to drive development of new validations/checks.

I never did really figure out exactly what was wrong, some combination of API calls to do with setting an icon on the GLFW window caused it to blow up - I just got it working by using the "right" combination of voodoo and moved on.
Problems arise around the dichotomy of Java scoping and stack scoping, which are orthogonal concepts that have unfortunately been mixed up in the API.

Cas

KaiHH: the problem was explained here: http://forum.lwjgl.org/index.php?topic=6871.msg36237#msg36237. An instance returned by GLFWImage.create was used in a try-with-resources block. For LWJGLX/debug, you should be able to detect the .close() call (which delegates to .free()) in the automatically generated finally block.

Btw, the debug allocator is catching this as an error (trying to free an allocation the allocator doesn't now about), but you may be able to produce a more useful/friendly error message.