[Solved] jME does not work -- at all -- on modern Java due to a regression

Troubleshooting General Help
1

I originally posted this issue on GIthub, but pspeed recommended also posting it here. As such, here the Github posts follow. I didn’t see any reason to edit them, as the information is nicely contained i them already.

My initial post:

I recently tried to work on some of my jME projects with Java 12, as I do for all of my Java projects, and I found that when jME starts (even with just a SimpleApplication with nothing being rendered beyond jME’s default statistic view), the application quickly crashes with a log like this one:

<date and time are redacted to protect my time zone> com.jme3.system.JmeDesktopSystem initialize
INFO: Running on jMonkeyEngine 3.2-stable
 * Branch: HEAD
 * Git Hash: 8291d61
 * Build Date: 2019-07-13
Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!

An example java -version for a Java implementation for which the error takes place:

OpenJDK Runtime Environment (build 12.0.2+10)
OpenJDK 64-Bit Server VM (build 12.0.2+10, mixed mode)

An example java -version for a Java implementation for which the error does not take place (jME works as expected):

openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-b05)
OpenJDK 64-Bit Server VM (build 25.222-b05, mixed mode)

OS: Arch Linux
OpenGl Implementation: Nvidia 430.34 on GTX 1070
Linux Kernel version: 5.2.3-arch1-1-ARCH

This issue is new as the project in question did work before (even a few weeks ago, if I recall correctly), but has since stopped working. There have been numerous possibly relevant updates to my system since then, as Arch Linux is a bleeding edge distribution that often gets hundreds of relevant updated packages in a single day. Most notably, both the Linux kernel and Nvidia driver have updated since I last remember the project in question working.

Pspeed’s reply:

So, if I get this straight… project was working fine. JME version was not changed. System was updated and JME stopped working.

If so then this is not a JME regression. I recommend discussing trouble shooting questions on the forum where you will get more eyes than the 2 or 3 people that would read this here.

My reply:

If so then this is not a JME regression.

I didn’t say that it was a JME regression, I said that it is a regression. I have no idea what the regression is in, but after some research on the Internet, it seems to be an LWJGL issue as I found it in the issue trackers of some other LWJGL projects. Unfortunately, I can’t debug further as I don’t understand LWJGL or JNI well enough to do so, or to write a good bug report to LWJGL. No other (non-LWJGL) programs have an issue on my system’s configuration, so it is probably a bug in LWJGL and/or the way that jME uses it.

I will also put this on the forum.

1 Like
2

but after some research on the Internet, it seems to be an LWJGL issue as I found it in the issue trackers of some other LWJGL projects

just based on what you said. Did you tried both jme-lwjgl and jme-lwjgl3 packages? both dont work?

3

Have you tried with JME 3.3.0-alpha2?

4

I added all of the library jars from here to my classpath. I don’t see any way to switch out which lwjgl version is being used based on that system, and I don’t know enough Maven or Gradle in order to do anything with those repositories (it’s on my list to learn, but a lot of other things are there too and there is only so much time that I can spend on learning things).

5

I have not. It doesn’t seem to be in the Github releases list. Is there somewhere where I can download it? I tried building the zip file that is distributed via Github releases using Gradle, but after poking around the available task list and trying a few with the master branch, I couldn’t find anything that gave any sort of zip like that.

6

Also releases are published to bintray :

3.3.0-alpha2 releases are already there.

1 Like
7

I just tested with 3.3.0-alpha2 and only the jme3-core, jme3-desktop, and jme3-lwjgl libraries. The same issue occurs with no change except version numbers:

<date and time are redacted to protect my time zone> com.jme3.system.JmeDesktopSystem initialize
INFO: Running on jMonkeyEngine 3.3-alpha2
 * Branch: HEAD
 * Git Hash: 3f1f2e8
 * Build Date: 2019-05-22
Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!```
8

If you add lwjgl, you use lwjgl2, if you add jme3-lwjgl3, you use lwjgl3.

9

Thank you! Using lwjgl3 fixes the issue.

2 Likes
10

does this anyway also mean LWJGL3 package is now more stable than 2 now?

11

Unclear to me… Could be that the next system update breaks lwjgl3 and fixes lwjgl2…

That’s the risk of being on the bleeding edge sometimes.

This seems like a native library linking issue and could probably happen to any precompiled binary, I guess.

12

well, we have Centos always up2date, had no problems like this. i dont know much about Arch linux.

I recently tried to work on some of my jME projects with Java 12

Anyway did system updated to Java 12 or it was earlier that version? maybe its just about java 12 dont work with jme-lwjgl package? (because when he changed to jme-lwjgl3 it work)

13

Except according to OP, Java 12 worked with it at one point and then stopped working.

We actually don’t know what the issue is, I guess. So anything is speculation. That library X works and library Y doesn’t isn’t enough on its own to decide what’s bad or not… given that nothing specific to the library X or Y was updated.

1 Like
14

A data-point that may offer some insight:

I’ve just had to troubleshoot a similar error in another app that uses jogl. I, like the OP, run Arch, but the issue was first reported by an Ubuntu user. (All versions of Java >8 for him)
On Arch, it broke after a Java 12 update. Java 10 is still good, not updated in a while.

I’ve found a few references to similar around the 'net, all related to loading native code modules.

This eclipse bug seems to have the most insight.

If they’re right, it’s going to depend on what version of glibc you jvm is using, and possibly what was present when your native payload was compiled.

Not sure if this helps, but perhaps a point for further investigation.

15

Important information.

Still seems like less a “JME problem” than a “Linux getting it’s sh*t together” problem. (Note: not trying to be down on Linux, I’m a fan… but this stuff is kind of what scares people off.)

16

I’ve been thinking about this for a bit. What is the difference between lwjgl2 & 3, in terms of how the native libraries are structured?

Answering that could give us some meat to throw to the people who maintain our JVM distributions.

I’ve reported my version of this issue as an Arch bug. @john01dav, is you have anything to add, would you attach it to that bug report?

17

LWJGL 2 & 3 are totally different internally. As I recall, LWJGL 2 used its own native code to bind Java <-> platform libs (GL, input, etc). LWJGL 3 uses auto-generated bindings for all of its native code, and it relies on GLFW for support for graphics (OpenGL & Vulkan), input, windowing etc.

2 Likes
18

Aha! So, it looks like lwjgl 3 is using a monolithic native library, where lwjgl 2 had at least a couple… Jinput has it’s own natives.

Might support the glibc bug hypothesis, as that bug is about loading multiple libraries in parallel…

2 Likes
19

I believe the “core” LWJGL is using one native library (GLFW), yes - but it is modular, so any of the plethora of extra libraries it provides are loaded from separate native libraries.

20

Do we have any way of knowing how many native libraries were involved in op’s test?