search

corretto / corretto-8

Amazon Corretto 8 is a no-cost, multi-platform, production-ready distribution of OpenJDK 8
GNU General Public License v2.0
2.11k stars 221 forks source link

SIGSEGV (0xb) at pc=0x4c8d4804e0c148f6, pid=46732, tid=0x00007faba7690700 #506

Open anup60 opened 7 months ago

anup60 commented 7 months ago

Thank you for taking the time to help improve OpenJDK and Corretto.

If your request concerns a security vulnerability then please report it by email to aws-security@amazon.com instead of here. (You can find more information regarding security issues at https://aws.amazon.com/security/vulnerability-reporting/.)

Otherwise, if your issue concerns OpenJDK 8 and is not specific to Corretto 8 we ask that you raise it to the OpenJDK community. Depending on your contributor status for OpenJDK, please use the [JDK bug system]() or the appropriate mailing list for the given problem area or update project jdk8u-dev.

If your issue is specific to Corretto 8, then you are in the right place. Please proceed with the following.


### Describe the bug
JVM crashes while running the application with below errors

A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x4c8d4804e0c148f6, pid=46732, tid=0x00007faba7690700
#
# JRE version: OpenJDK Runtime Environment (8.0_382-b05) (build 1.8.0_382-b05)
# Java VM: OpenJDK 64-Bit Server VM (25.382-b05 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  0x4c8d4804e0c148f6

### To Reproduce
Always the issue reproduces

### Expected behavior
JVM should not crash

### Screenshots
If applicable, add screenshots to help explain your problem.

### Platform information
    OS:NAME="SLES"
VERSION="15-SP4"
VERSION_ID="15.4"
PRETTY_NAME="SUSE Linux Enterprise Server 15 SP4"
ID="sles"
ID_LIKE="suse"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:15:sp4"
DOCUMENTATION_URL="https://documentation.suse.com/"

hs_err_pid12346.log

Additional context

Add any other context about the problem here.

For VM crashes, please attach the error report file. By default the file name is hs_err_pidpid.log, where pid is the process ID of the process.

anup60 commented 7 months ago

Could you please help on this

eastig commented 6 months ago

Hi @anup60, There is not enough information in the provided hs_err file to identify the root cause of the crash. Do you have more crash files?

In the hs_err file I see libraries which are not a part of corretto:

/usr/g/PET/lib64/linux2/libCalCfgFile.so
/usr/g/PET/lib64/linux2/libCalFile.so
/usr/g/PET/lib64/linux2/libCalUiUtil.so
/usr/g/PET/lib64/linux2/libDetCalCommon.so
/usr/g/PET/lib64/linux2/libErr.so
/usr/g/PET/lib64/linux2/libH5Wrap.so
/usr/g/PET/lib64/linux2/libRawPrimitives.so
/usr/g/PET/lib64/linux2/libRdfUtils.so
/usr/g/PET/lib64/linux2/libSipmGainCal.so
/usr/g/PET/lib64/linux2/libUniformCalFile.so
/usr/g/PET/lib64/linux2/libcfg.so
/usr/g/PET/lib64/linux2/libconfigMgr.so
/usr/g/PET/lib64/linux2/libdbUtils.so
/usr/g/PET/lib64/linux2/libfile.so
/usr/g/PET/lib64/linux2/libgebase2.so
/usr/g/PET/lib64/linux2/libobrivn.so
/usr/g/PET/lib64/linux2/libpetbase.so
/usr/g/PET/lib64/linux2/libpetlwc.so
/usr/g/PET/lib64/linux2/librdf.so
/usr/g/PET/lib64/linux2/librdfCpp.so
/usr/g/PET/parc/lib64/libhdf5.so.10.3.0
/usr/g/PET/parc/lib64/libhdf5_hl.so.10.2.0
/usr/g/ctuser/nuevo/lib64/libdbxi.so
/usr/g/ctuser/nuevo/lib64/libdbxnuevo.so
/usr/g/ctuser/nuevo/lib64/libdbxpg.so
/usr/g/ctuser/nuevo/lib64/libdbxtk.so
/usr/g/ctuser/nuevo/lib64/libdbxtri.so
/usr/g/ctuser/nuevo/lib64/libdmf.so
/usr/g/ctuser/nuevo/lib64/libdmfdicom.so
/usr/g/ctuser/nuevo/lib64/libicudata.so.42.1
/usr/g/ctuser/nuevo/lib64/libicui18n.so.42.1
/usr/g/ctuser/nuevo/lib64/libicuuc.so.42.1
/usr/g/ctuser/nuevo/lib64/libnvoer.so
/usr/g/ctuser/nuevo/lib64/libsslwrapper.so
/usr/g/ctuser/nuevo/lib64/libterrautil.so
/usr/g/ctuser/terra/lib64/libtca.so

Does you application or any your libraries use JNI? The crash might be originated from the native code.

anup60 commented 6 months ago

Hi @eastig,

Thankyou for the update. When i debug using gdb I could see the failure is happening with the below library

[Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00007fa476dcad20 in __pthread_clockjoin_ex () from /lib64/libpthread.so.0 Missing separate debuginfos, use: zypper install java-1.8.0-amazon-corretto-devel-debuginfo-1.8.0_382.b05-1.x86_64 (gdb) c Continuing.

Thread 48 "Thread-3" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fa3b8e11700 (LWP 8028)] 0x00007fa46194dabd in ?? () (gdb) c Continuing. [Detaching after vfork from child process 10420] [New Thread 0x7fa388d88700 (LWP 10421)]

Thread 48 "Thread-3" received signal SIGSEGV, Segmentation fault. 0x00007fa46137bcce in ?? () (gdb) c Continuing.

Thread 48 "Thread-3" received signal SIGSEGV, Segmentation fault. 0x00007fa4762b2ee0 in os::print_hex_dump(outputStream, unsigned char, unsigned char*, int) () from /usr/java64/java-1.8.0-amazon-corretto/jre/lib/amd64/server/libjvm.so (gdb) c Continuing.

Thread 48 "Thread-3" received signal SIGABRT, Aborted. 0x00007fa4769f6c6b in raise () from /lib64/libc.so.6 (gdb) c Continuing.

anup60 commented 6 months ago

Hi @eastig,

Please see some more information.

Here we build this application in 32-bit java 1.8 jdk

Java(TM) SE Runtime Environment (build 1.8.0_201-b09) Java HotSpot(TM) Server VM (build 25.201-b09, mixed mode)

and we run this application in 64 bit amazon corretto jvm

openjdk version "1.8.0_382" OpenJDK Runtime Environment Corretto-8.382.05.1 (build 1.8.0_382-b05) OpenJDK 64-Bit Server VM Corretto-8.382.05.1 (build 25.382-b05, mixed mode)

Is there any compatibility issue here

eastig commented 6 months ago

Is there any compatibility issue here

Nope.

BTW, you are using a very old build of Corretto 8: 8.382.05.1. The latest is 8.412.08.1. Can you try the latest one?

apancorb commented 5 months ago

Hi @eastig,

I am getting the same error. I am using 1.8.0_412-b08. The strange part is that this was not happening a month ago.

Here is the log file: hs_err_pid2525.log

eastig commented 5 months ago

Hi @apancorb, Your crash might be different from the one reported by @anup60. Do you have a reproducer? Your JVM options:

jvm_args: -XX:MaxMetaspaceSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xms256m -Xmx512m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant

Can you make Xms and Xmx having the same value? If it does not work, can you also add -XX:-ReduceInitialCardMarks?