FS#63429 - [jre-openjdk] Native crash when loading certain native libraries

Attached to Project: Arch Linux
Opened by Lucas S (sailsman63) - Sunday, 11 August 2019, 01:44 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:15 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No



Attempting to run a java program that uses jogl (jogamp.org) will crash out the JVM with the following error:

Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!

Removing the jogl native packages from the program classpath (forcing a fallback to a non-jogl option) allows the program to run normally.

This is _new_ behavior. It is not seen in jre10-openjdk or jre8-openjdk, and was not seen in jre-openjdk 12.0.1.u12-1.

Additional info:
* jre-openjdk 12.0.2.u10-1
* Current glibc version: 2.29-4
* This issue has also been observed with lwjgl3. See https://hub.jmonkeyengine.org/t/solved-jme-does-not-work-at-all-on-modern-java-due-to-a-regression/42112.

Steps to reproduce:

- Launch a java application that uses the indicated libraries.
- Watch the terminal output.
- Observe that removing the jogl and gluegen _natives_ libraries prevents this bug. (by stopping the system from attempting the load that crashes)

The application that I'm working from is: https://sourceforge.net/projects/aoi/files/ArtOfIllusion/3.1.0/Art%20Of%20Illusion%203.1.0%20Generic%20No-Install.zip

(I'm one of the maintainers of that application. Sorry, not duplicated with an Arch package at this time.)

The included jogl libraries are copied directly from jogamp.org's current stable deployment. (https://jogamp.org/deployment/jogamp-current/)
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:15 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/java-openjdk/issues/1
Comment by Tassilo Horn (tsdh) - Wednesday, 25 September 2019, 11:32 GMT
I have the same issue with our application at work when using

core/glibc 2.29-4


extra/jdk11-openjdk 11.0.4.u11-1
extra/jre11-openjdk 11.0.4.u11-1
extra/jre11-openjdk-headless 11.0.4.u11-1


extra/jdk-openjdk 12.0.2.u10-1
extra/jre-openjdk 12.0.2.u10-1
extra/jre-openjdk-headless 12.0.2.u10-1

A slightly older version of our application works with the same JDKs. I think it's probably a new or updated dependency which causes the crash though I'm unable to find out the culprit since the "Inconsistency detected by ld.so..." message is the only output and I don't know when it happens. (Pointers welcome!)

On the positive side, simply switching to

aur/jdk11-adoptopenjdk 11.0.4.u11-1 (5 | 0.65) [installed]
OpenJDK Java 11 development kit (AdoptOpenJDK build)

fixed the issue for me.
Comment by techge (techge) - Monday, 07 October 2019, 17:47 GMT
I just ran into the same issue. Using java-10-openjdk instead of java-11-openjdk or java-12-openjdk helped me, too.
Comment by Lucas S (sailsman63) - Wednesday, 09 October 2019, 20:00 GMT
Just updating: This is still an issue with the newly updated java 13.u33-1.

Asking users to install a non-standard JRE is _not_ a good workaround.

All the similar issues that I have heard about seem to include trying to load 2 or more native libraries in very close succession.
Comment by Tassilo Horn (tsdh) - Tuesday, 21 January 2020, 06:12 GMT
Since aur/jdk11-adoptopenjdk has bumped its version to 11.0.6.u10-1, I get this error also with that java 11 distribution. Therefore I removed it and installed the standard extra/jdk11-openjdk 11.0.6.u10-1. That also crashes.

This means that currently I cannot start the client part of the application I'm getting paid to develop. So at least for me, the severity is not "low" anymore.

(Oh, it seems like I still have the working aur/jdk11-adoptopenjdk 11.0.4.u11-1 tarball in my pacman package cache! Lucky me!)
Comment by Tassilo Horn (tsdh) - Tuesday, 21 January 2020, 06:34 GMT
I get this crash also with extra/jdk-openjdk 13.0.1.u9-1.

By the way: why is the net full of people having this exact issue, yet I'm unable to find a bug report at https://bugs.openjdk.java.net/?
Comment by Tassilo Horn (tsdh) - Wednesday, 22 January 2020, 05:41 GMT
Somewhere I found the tip to run the program using LD_DEBUG=all to see which symbol fails the assertion. That's what I did:

11495: symbol=__cxa_finalize; lookup in file=/usr/lib/jvm/java-11-openjdk/bin/java [0]
11495: symbol=__cxa_finalize; lookup in file=/usr/lib/jvm/java-11-openjdk/bin/../lib/jli/libjli.so [0]
11495: symbol=__cxa_finalize; lookup in file=/usr/lib/libc.so.6 [0]
11495: binding file /tmp/JxBrowser/7.2/libawt_helper.so [0] to /usr/lib/libc.so.6 [0]: normal symbol `__cxa_finalize' [GLIBC_2.2.5]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/jvm/java-11-openjdk/bin/java [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/jvm/java-11-openjdk/bin/../lib/jli/libjli.so [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libc.so.6 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libz.so.1 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libdl.so.2 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libpthread.so.0 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/lib64/ld-linux-x86-64.so.2 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/jvm/java-11-openjdk/lib/server/libjvm.so [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libstdc++.so.6 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libm.so.6 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libgcc_s.so.1 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/jvm/java-11-openjdk/lib/libawt_xawt.so [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/jvm/java-11-openjdk/lib/libawt.so [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libXext.so.6 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libX11.so.6 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libXrender.so.1 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libXtst.so.6 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libXi.so.6 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/jvm/java-11-openjdk/lib/libjava.so [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libxcb.so.1 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/jvm/java-11-openjdk/lib/libverify.so [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libXau.so.6 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libXdmcp.so.6 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libgio-2.0.so [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libglib-2.0.so.0 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libgobject-2.0.so.0 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libgmodule-2.0.so.0 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libmount.so.1 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libresolv.so.2 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libpcre.so.1 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libffi.so.6 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libblkid.so.1 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/librt.so.1 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/tmp/JxBrowser/7.2/libawt_helper.so [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/libpthread.so.0 [0]
11495: symbol=JAWT_GetAWT; lookup in file=/usr/lib/jvm/java-11-openjdk/bin/../lib/libjawt.so [0]
Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!

Ok, so I know JAWT_GetAWT is the culprit. That's indeed a JDK function

Header: https://hg.openjdk.java.net/jdk/jdk/file/9d7d74c6f2cb/src/java.desktop/share/native/include/jawt.h#l338
Source: https://hg.openjdk.java.net/jdk/jdk/file/9d7d74c6f2cb/src/java.desktop/unix/native/libjawt/jawt.c#l40

and guessing from the name of header/source, I would assume the last lookup in /usr/lib/jvm/java-11-openjdk/bin/../lib/libjawt.so should have found it.
Comment by Lucas S (sailsman63) - Wednesday, 22 January 2020, 06:08 GMT
As to why there is no OpenJDK bug:

I've found the bug-tracker there to be very Opaque, not worth signing up for a single bug report. Perhaps this is intentional? Keep drive-by reports to a minimum?

However, this means that only the more dedicated/experienced are likely to post there. Hopefully after doing enough (intelligent) testing so that the report would actually be useful to the team.

That's honestly why I posted here, even though I suspected that the issue was further upstream. I hoped that some of the maintainers of the arch package would be able to help me refine this into a more... actionable report.

Unfortunately, this is still marked as "Unconfirmed" and none of the jre/jdk maintainers has even asked for further information...

Ubuntu is even worse - they just say that affected libraries "Are only compatible with java 8" without justifying that assertion. So... bunch of end users dealing with the same issue, but no one with the know-how or experience able to make a more specific report further upstream.
Comment by Lucas S (sailsman63) - Wednesday, 22 January 2020, 06:15 GMT
Also, as a side note, the binaries that jogamp has been providing for 2.4.0rc builds _do_ work with the newer JRE releases, as well as maintaining compatibility back to Java 8, at least.

It is not clear if there were actual code changes involved there, or just compiling the native components against a newer JNI core library.
(I was never able to get the jogamp libraries to build correctly, even when following their directions precisely. They do some rather peculiar things with using one version of javac, while insisting on a different version of the java core classes to compile against. Their instructions assume that there are Global classpath and such, whereas Arch JRE's set all of that up with the launch script)
Comment by Mike Hogye (stacktracer) - Friday, 31 January 2020, 21:16 GMT
I'm encountering this problem on extra/jre11-openjdk 11.0.4.u11-1 (and later). Works fine on extra/jre11-openjdk 11.0.4.u7-1.
Comment by Mike Hogye (stacktracer) - Monday, 03 February 2020, 14:55 GMT
(Deleted accidental duplicate post.)
Comment by Mike Hogye (stacktracer) - Sunday, 23 February 2020, 22:58 GMT
I no longer see this problem on extra/jre11-openjdk 11.0.6.u10-1. That's the same version that WAS having the problem a few weeks ago.

Not sure what the relevant change was. I did a full system update today; something in there must have fixed the problem. Doesn't seem to have been the glibc update ... I just downgraded glibc back to where it was a few weeks ago (2.30-3), and that doesn't cause the problem to reappear. Beats me.
Comment by Tassilo Horn (tsdh) - Monday, 08 June 2020, 09:04 GMT
Now I have the issue again with extra/jdk11-openjdk 11.0.7.u10-1. However, I don't get it with aur/jdk11-adoptopenjdk 11.0.7.u10-1.
Comment by ITA84 (ITA84) - Sunday, 04 October 2020, 14:43 GMT
Just wanted to report that I have the same issue with a Java game that uses lwjgl (Spiral Knights); the problem persists with the current OpenJDK 11 version (11.0.8+10) and isn't present with OpenJDK 8 (1.8.0_265-b01, but also the previous ones) or with the AdoptOpenJDK 11 build I've tried (same version 11.0.8+10).

This seems to be the same bug as reported for Ubuntu here (still unresolved): https://bugs.launchpad.net/ubuntu/+source/openjdk-lts/+bug/1838740
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.