You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ThoSap
changed the title
[Native Image] Application crashes after the second heap dump using kill -SIGUSR1 <pid>
[Native Image] Application crashes with segfault after the second heap dump using kill -SIGUSR1 <pid>Oct 16, 2024
To clarify, if I make a heap dump immediately after the first one or only with a few minutes in between, the application does not crash.
It only crashes if I make a heap dump after 20 to 30 minutes of runtime.
ThoSap
changed the title
[Native Image] Application crashes with segfault after the second heap dump using kill -SIGUSR1 <pid>
[Native Image] G1 GC application crashes with segfault after a second heap dump using kill -SIGUSR1 <pid>Oct 17, 2024
Thank you for reaching out to us!
Could you please provide us with a concise reproducer that I can test locally on my machine for your issue alongside the steps needed to reproduce it?
As I haven't heard back from you in over three weeks, I will be closing this issue for now. If you
need further assistance or have any updates, please feel free to reach out at any time.
Thank you for your understanding.
Describe the Issue
If I follow the following steps to create a heap dump using
kill -SIGUSR1 <pid>
on runtime, my application running with the G1 GC always crashes with a segfault after I make the second heap (after some time in between, for example, 30 minutes) dump using the command.https://www.graalvm.org/jdk21/reference-manual/native-image/guides/create-heap-dump/#:~:text=Create%20Heap%20Dumps%20with%20SIGUSR1%20(Linux/macOS%20only)
I added
-XX:+PrintGC -XX:+VerboseGC
after this issue occurred for the first time, to see normal GC runs in runtime before the full GC heap dump crash.Using the latest version of GraalVM can resolve many issues.
Latest JDK 21.0.5 version
GraalVM Version
Built using container image
container-registry.oracle.com/graalvm/native-image:21.0.5
->
container-registry.oracle.com/graalvm/native-image:21.0.5-ol9-20241015
-> Oracle Container Registry Image ID
1e7548c6ff98
-> Repo Digest
container-registry.oracle.com/graalvm/native-image@sha256:c10d7f10da5bfed22ad02887e96095b1c08d42c8e6bf03d774cded332fa444a9
-> Image ID (output from docker images)
sha256:f8a4dcaa07bfa79d6e8f4dced149d28a86e802fcdfe20586b69dd93570c2e82d
java version "21.0.5" 2024-10-15 LTS Java(TM) SE Runtime Environment Oracle GraalVM 21.0.5+9.1 (build 21.0.5+9-LTS-jvmci-23.1-b48) Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 21.0.5+9.1 (build 21.0.5+9-LTS-jvmci-23.1-b48, mixed mode, sharing)
Operating System and Version
Linux mycontainername 5.15.0-209.161.7.2.el8uek.x86_64 #2 SMP Tue Aug 20 10:44:07 PDT 2024 x86_64 x86_64 x86_64 GNU/Linux
Diagnostic Flag Confirmation
-H:ThrowMissingRegistrationErrors=
flag.Run Command
./application -Dquarkus.http.host=0.0.0.0 -Djava.util.logging.manager=org.jboss.logmanager.LogManager -XX:+PrintGC -XX:+VerboseGC
Expected Behavior
I should be able to create multiple heap dumps on runtime using
kill -SIGUSR1 <pid>
without a segfault.Actual Behavior
Executing
kill -SIGUSR1 <pid>
twice (after some time in between, like 30 minutes) crashes the application with a segfault.Steps to Reproduce
My application was built with Quarkus 3.15.1 and
container-registry.oracle.com/graalvm/native-image:21.0.5-ol9-20241015
with the following native-image build command.I enabled the heapdump using
--enable-monitoring=heapdump,jfr,jvmstat
and created the heapdump using https://www.graalvm.org/jdk21/reference-manual/native-image/guides/create-heap-dump/#:~:text=Create%20Heap%20Dumps%20with%20SIGUSR1%20(Linux/macOS%20only)The native-image is running in the base container image
registry.access.redhat.com/ubi9/ubi-minimal:9.4
.Additional Context
No response
Run-Time Log Output and Error Messages
https://gist.github.com/ThoSap/e6b01fe3677c2e89a3716a1ac66e85eb
The text was updated successfully, but these errors were encountered: