JVM crash on Ubuntu 21

[sheidrich-inet]

Hello,

while testing our application on a new Ubuntu 21 system, a JVM crash always occurred during startup.
Upon closer analysis we saw that this crash is in the native code.

We are trying to read in an image with OpenJpeg at this point. The code looks something like this:

        System.setProperty( "jnr.ffi.library.path", "<path>" );
       
        // to get a better message and exception before the registration
        new OpenJpeg();

        // register in ImageIO
        IIORegistry registry = IIORegistry.getDefaultInstance();
        registry.registerServiceProvider( new OpenJp2ImageReaderSpi() );
        registry.registerServiceProvider( new OpenJp2ImageWriterSpi() );

        // test if it is working
        try (InputStream testLogo = getClass().getResourceAsStream( "verification.jp2" ) ){
            BufferedImage testImage = ImageIO.read( testLogo );
            if( testImage == null ) {
                throw new IOException( "OpenJpeg library not initalized correctly, Jpeg2000 images will not be displayed." );
            }
        } catch (Throwable e) {
		e.printStackTrace();
	}

The crash happened while reading the image with

BufferedImage testImage = ImageIO.read( testLogo );

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f0773223189, pid=7642, tid=7655
#
# JRE version: OpenJDK Runtime Environment Temurin-11.0.12+7 (11.0.12+7) (build 11.0.12+7)
# Java VM: OpenJDK 64-Bit Server VM Temurin-11.0.12+7 (11.0.12+7, mixed mode, tiered, compressed oops, serial gc, linux-amd64)
# Problematic frame:
# C  [jffi15575292289148801085.so+0x7189]
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/dev/core.7642)
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

I upload the error log file and hope you can tell me, whats the problem is and how to solve it. With an older Ubuntu this works.

hs_err_pid7642.log

Best regards,

S. Heidrich

[Horcrux7]

This is a crash log with System.setProperty( "jnr.ffi.asm.enabled", "false" );
hs_err_pid2558.log

It looks a little different. We tried it, hoping to find a workaround and the cause of the crash.

It is also possible to set a breakpoint at the last non-native method before the crash. So it is not a timing or threading issue.

[Horcrux7]

Possible Workarounds

• Looking for a workaround, we scaled down our application (removing many optional plugins/jar files) and that solved the problem.
• If the native code was initialized before the first full GC, it works without VM crash.
• If we calling System.gc() in our code it crash also with Java 17 which has work before.
• But in a simple test program a System.gc() does not force the crash.
• Only calling StubLoader.isLoaded(); at a very early stage does not help. Only the early init of the imageio-openjpeg library seems to solve the problem.

If we can present any helpful information then tell us how we can do this.

[headius]

I missed this over the holiday. Thank you for the report!

Does this reproduce consistently? I am not an expect on debugging native code but if I can reproduce there's a good chance I can find the problem.

[Horcrux7]

Yes, it was reproducible consistently. We have try it on two Ubuntu 21 systems and it crash ever on every run.

Because this not occur with a simple test case you can download our SDK at https://download.inetsoftware.de/clear-reports-sdk-latest.zip
And run the start script i-net Clear Reports\startDesigner.sh or i-net Clear Reports\startServer.sh. After 30-60 seconds it will crash.

The jnr files are in the plugin i-net Clear Reports\plugins\jpeg2000.zip. You can replace the jar files in this plugin with debug versions or newer versions if you want.

Or for simpler debugging in an IDE you can set the Java command line switch -Djpeg2000.classpath=<path to classes> (without slash at path end)

[gamma]

I can now reproduce the issue with an eclipse-temurin:17-jre-alpine Docker image as well. See hs_err_pid165.log

Are there any updates on this issue?

[gamma]

Here is another update: the crash always occurs with eclipse-temurin Java VMs, I checked v11 to v17. The Adoptium 11 Java VM does not crash, so there may be an issue with either them or this library.

[gamma]

Here is another update. I created an issue with the Temurin support at: adoptium/adoptium-support#477 - you can use the sample code there as well.

[headius]

I will try to reproduce today and see if I can find a problem.

[Horcrux7]

The new crash is related to a incompatibility of glibc and musl. Alpine use musl and the native library was compiled with glibc. If there can be a helpful exception would be a great improvement if this is possible. A crash is very bad.

Details can you find at: dbmdz/imageio-jnr#192

The old crash with Ubuntu 21 have we solve with switching to Java 17. You can close this issue if there is no improvement possible in such a case.