Closed pwagland closed 3 years ago
@dmitripivkine fyi @manqingl can you help decode the stack trace pls.
@pwagland is there any system core file? It's unlikely we can do much without one.
Looks like IJ30975
https://www.ibm.com/support/pages/apar/IJ30975
(0x00007FEC426A9E2C [libj9prt29.so+0x2ee2c]) : 0x2ee2c <writeSpec+44> [../../../../../../omr/port/common/omrstr.c:727]
(0x00007FEC426ABF73 [libj9prt29.so+0x30f73]) : 0x30f73 <omrstr_vprintf+1859> [../../../../../../omr/port/common/omrstr.c:1020]
(0x00007FEC426982A0 [libj9prt29.so+0x1d2a0]) : 0x1d2a0 <omrfile_vprintf+64> [../../../../../../omr/port/unix/omrfile.c:939]
(0x00007FEC4269846F [libj9prt29.so+0x1d46f]) : 0x1d46f <omrfile_printf+207> [../../../../../../omr/port/unix/omrfile.c:984]
(0x00007FEC4057FC98 [libj9vrb29.so+0x58c98]) : 0x58c98 <MM_VerboseWriterFileLoggingSynchronous [../../../../../../omr/gc/verbose/VerboseWriterFileLoggingSynchronous.cpp:129]
(0x00007FEC4057F604 [libj9vrb29.so+0x58604]) : 0x58604 <MM_VerboseWriterChain [../../../../../../omr/gc/verbose/VerboseWriterChain.cpp:126]
(0x00007FEC4057C2B2 [libj9vrb29.so+0x552b2]) : 0x552b2 <MM_VerboseHandlerOutput [../../../../../../omr/gc/verbose/VerboseHandlerOutput.cpp:547]
(0x00007FEC4225B3BE [libj9hookable29.so+0x13be]) : 0x13be <J9HookDispatch(J9HookInterface**, uintptr_t, void*)+302> [../../../../../../../omr/util/hookable/hookable.cpp:238]
(0x00007FEC408E996C [libj9gc29.so+0x11096c]) : 0x11096c <MM_EnvironmentBase [../../../../../../omr/gc/base/EnvironmentBase.cpp:233]
(0x00007FEC408EA67C [libj9gc29.so+0x11167c]) : 0x11167c <MM_EnvironmentBase [../../../../../../omr/gc/base/EnvironmentBase.cpp:496]
(0x00007FEC409103C2 [libj9gc29.so+0x1373c2]) : 0x1373c2 <OMR_GC_AllocateObject(OMR_VMThread*, MM_AllocateInitialization*)+482> [../../../../../../omr/gc/base/AllocateInitialization.hpp:243]
(0x00007FEC4081F43F [libj9gc29.so+0x4643f]) : 0x4643f <J9AllocateIndexableObject(J9VMThread*, J9Class*, uint32_t, uintptr_t)+1759> [../../../../../openj9/runtime/gc_modron_startup/mgcalloc.cpp:550]
(0x00007FEC415F679A [libj9jit29.so+0x94b79a]) : 0x94b79a <old_slow_jitNewArray(J9VMThread*)+186> [../../../../../openj9/runtime/codert_vm/cnathelp.cpp:1182]
(0x00007FEC41609091 [libj9jit29.so+0x95e091]) : 0x95e091 <jitNewArray+97> [/home/adoptopenjdk/workspace/build-scripts/jobs/jdk11u/jdk11u-linux-x64-openj9/workspace/build/src/build/linux-x86_64-normal-server-release/vm/runtime/codert_vm/xnathelp.s:595]
@pwagland this is a known problem which has since been fixed (https://github.com/eclipse/omr/pull/5806), please use a newer build.
Thank you for the prompt reply! We will try the 11.0.11 release.
Java -version output
Output from
java -version
.Summary of problem
We have seen an issue where relatively unused, but not totally idle, systems are crashing after about two weeks when running using Java 11.0.10. This cannot be reproduced at will, it seems that about 5% of our containers will die after about two weeks.
Diagnostic files
We have the following printed to stdout:
For each crash, it appears to be crashing while allocating a byte array. Five thread dumps from the thread that is running at the points of the crashes:
We do have
Snap
,javacore
, andverbosegc
files for each crash. I can share these directly with someone investigating this issue further.What can we do to help diagnose this further?