JVM crash (SIGSEGV at ~StubRoutines::jshort_disjoint_arraycopy)

[vinzenzgruppe]

Please provide a brief summary of the bug

The program starts without errors but after some hours it crashes with SIGSEGV
hs_err_pid4070021.log

Did you test with the latest update version?

• Yes

Please provide steps to reproduce where possible

No response

Expected Results

continues running without crash

Actual Results

crash SIGSEGV

What Java Version are you using?

openjdk version "21.0.5" 2024-10-15 LTS OpenJDK Runtime Environment Temurin-21.0.5+11 (build 21.0.5+11-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.5+11 (build 21.0.5+11-LTS, mixed mode, sharing)

What is your operating system and platform?

Ubuntu 22.04.5 x86_64

How did you install Java?

tar.gz

Did it work before?

yes, we updated from openjdk (temurin) 11.0.24+8 to Java 21, but we had to update some libs for compatibility reasons

Did you test with other Java versions?

yes, with jdk-21.0.4+7 and jdk-21.0.5+11 -> same results

Relevant log output

No response

[karianna]

It looks like you're running in a container is that correct?

[vinzenzgruppe]

It runs on a vmWare virtual machine, but no docker.

[karianna]

Hmmm, I checked the OpenJDK bug tracker and nothing like this has been reported elsewhere. Are you able to try running memtest in the VM or do you have access to the underlying host to run physical memory checkers?

[vinzenzgruppe]

Thanks for your reply karianna

I’m not sure if it is a problem with the physical memory,
because we have six dumps on this host with the crash reason (SIGSEGV at ~StubRoutines::jshort_disjoint_arraycopy).
We run the same java program on another vmware host and it also crashed already two times with the same reason (java version on this host is Temurin-21.0.4+7) .
I think if there is really a problem with the physical memory than these hosts will crash randomly with different reasons.

Meanwhile i try to find out if it is possible to check the physical memory of the vm server,
but that seems to be difficult, because a lot of productive hosts also run on this server.

[karianna]

Ah! Good to know it's crashed on more than one server, yeah that's very unlikely to be a RAM problem. OK next thing...

Can you give an insight as to what the app does? Are there any native components (I notice you print NMT stats)?

It looks like you might be serializing a bit of media. Can I ask what versions of Glassfish and jackson you're using?

[vinzenzgruppe]

Sorry for the long wait

The application is an api for other java programs running on this host.
It is used to manage the state(stop/start), set used libraries, set start options, get logs or state of the managed programs, ... .
To do this tasks the api reads properties of running java VMs, manages config files, executes scripts, ...

We have some monitoring tools which call the api periodically and alert on problems, so it is difficult to find out which api call leads to the crash.

For the webservice we use Glassfish/Jersey and Jackson as you already found out.

These are most of the used libraries with version:

org.glassfish.jersey.core jersey-server 3.1.8
org.glassfish.jersey.containers jersey-container-jdk-http 3.1.8
org.glassfish.jersey.containers jersey-container-servlet 3.1.8
org.glassfish.jersey.media jersey-media-json-jackson 3.1.8
org.glassfish.jersey.media jersey-media-json-processing 3.1.8
org.glassfish.jersey.media jersey-media-multipart 3.1.8
org.glassfish.jersey.media jersey-media-sse 3.1.8
org.glassfish.jersey.inject jersey-hk2 3.1.8
org.glassfish.jersey.bundles.repackaged jersey-guava 2.25.1
org.glassfish.hk2 hk2-api 3.1.1
org.glassfish.hk2 guice-bridge 3.1.1
org.glassfish.jaxb jaxb-runtime 4.0.5
com.fasterxml.jackson.datatype jackson-datatype-jsr310 2.7.5
com.google.inject guice 7.0.0
org.apache.commons commons-compress 1.20
com.google.guava guava 33.3.1-jre
jakarta.activation jakarta.activation-api 2.1.3
jakarta.servlet jakarta.servlet-api 6.1.0
jakarta.ws.rs jakarta.ws.rs-api 3.1.0
ch.qos.logback logback-classic 1.1.7
cz.jirutka.rsql rsql-parser 2.1.0
net.sourceforge.jtds jtds 1.3.1
eu.infomas annotation-detector 3.0.5
org.slf4j slf4j-api 1.7.21

NMT diff output is attached as file.
The reference(VM.native_memory basline) was taken about 15min after start and this output is the difference (VM.native_memory summary.diff) which was taken about three hours after start.

NmtDiffAfter3Hours.txt