corretto / corretto-17

Amazon Corretto 17 is a no-cost, multi-platform, production-ready distribution of OpenJDK 17
GNU General Public License v2.0
214 stars 50 forks source link

JVM crashes, when i trying get access for JNI libraries #155

Closed lolMatrix closed 10 months ago

lolMatrix commented 10 months ago

My device configuration is: Mac m1 SoC, jvm running in Rosetta 2 (x86_64 compatibility), 8gb ram. Used library dl4j. Trying access to keras model in a h5 file. Before updating code worked in normaly. After update on 17.0.9 i get next error

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000010e68a9bb, pid=96449, tid=11011
#
# JRE version: OpenJDK Runtime Environment Corretto-17.0.9.8.1 (17.0.9+8) (build 17.0.9+8-LTS)
# Java VM: OpenJDK 64-Bit Server VM Corretto-17.0.9.8.1 (17.0.9+8-LTS, mixed mode, emulated-client, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
# Problematic frame:
# V  [libjvm.dylib+0x5939bb]  jni_SetLongField+0xcb
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/<dont_read_my_profile (:>/catbot/hs_err_pid96449.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/corretto/corretto-17/issues/
#

Report file hs_err_pid96449.log. Thanks for answering :)

Fuji1405116 commented 10 months ago

I experienced similar kind of issue and its mainly due to crash in native code, JVM tends to crash while JNI interfaced native code crashes. So please check in native code whether the file access is permitted or properly configured from native code. Probably more experienced person with the ability to parse the log file can surely give you more insight

eastig commented 10 months ago

Hi @lolMatrix, Thank you for reporting and sharing the log file. According to the stack trace:

V  [libjvm.dylib+0x5939bb]  jni_SetLongField+0xcb
C  [libjnihdf5.dylib+0x8196]  Java_org_bytedeco_hdf5_Attribute_read__Lorg_bytedeco_hdf5_DataType_2Lorg_bytedeco_javacpp_BytePointer_2+0x2a6
j  org.bytedeco.hdf5.Attribute.read(Lorg/bytedeco/hdf5/DataType;Lorg/bytedeco/javacpp/BytePointer;)V+0
j  org.deeplearning4j.nn.modelimport.keras.Hdf5Archive.readAttributeAsString(Lorg/bytedeco/hdf5/Attribute;)Ljava/lang/String;+42

the crash happened when the native code Java_org_bytedeco_hdf5_Attribute_read__Lorg_bytedeco_hdf5_DataType_2Lorg_bytedeco_javacpp_BytePointer_2 called JVM jni_SetLongField. This might mean that the native code might have passed invalid arguments.

From the log, I see you use JavaCPP presets (https://github.com/bytedeco/javacpp-presets) hdf5-1.12.1-1.5.7-macosx-x86_64 which the native code belongs to.

According to https://github.com/bytedeco/javacpp-presets/tree/master/hdf5, the latest is 1.14.1-1.5.9. Yours is 1.12.1-1.5.7.

We recommend to update your JavaCPP preset for HDF5 and check whether the crash still happens.

BTW, according to https://www.hdfgroup.org/downloads/hdf5/, they provide the HDF5 library for MacOS M1. With them you don't need to use Rosetta.

lolMatrix commented 10 months ago

@eastig Thanks for your answer. You'll be right, i had version conflict. I have need for Rossetta, because my dependencies have only x86_64 native cpp code. Ok, back to mine problem. I resolve my problem with downgrade byteco libreries to 1.5.5.

Thanks for your attention and sorry for your spent time!

eastig commented 10 months ago

Hi @lolMatrix

Thanks for your attention and sorry for your spent time!

No worries. I am glad I helped you. You are welcome.