JDK-8329656 : assertion failed in MAP_ARCHIVE_MMAP_FAILURE path: Invalid immediate -5 0
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 22,23
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-04-04
  • Updated: 2024-04-16
  • Resolved: 2024-04-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 22 JDK 23
22.0.2Fixed 23 b18Fixed
Related Reports
Relates :  
Description
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/workspace/open/src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp:70), pid=214167, tid=214170
#  assert(immediate > 0 && Assembler::operand_valid_for_logical_immediate( false, immediate)) failed: Invalid immediate -5 0
#
# JRE version:  (23.0+1) (fastdebug build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 23-galahad+1-321, mixed mode, sharing, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x90e4f8]  CompressedKlassPointers::reserve_address_space_for_compressed_classes(unsigned long, bool, bool)+0x1f8
#
#

Host: ol8-aarch64-681390, AArch64, 8 cores, 30G, Oracle Linux Server release 8.8
Time: Thu Apr  4 03:56:12 2024 UTC elapsed time: 0.071721 seconds (0d 0h 0m 0s)

---------------  T H R E A D  ---------------

Current thread (0x0000ffff8c02df30):  JavaThread "Unknown thread" [_thread_in_vm, id=214170, stack(0x0000ffff91d3f000,0x0000ffff91f3d000) (2040K)]

Stack: [0x0000ffff91d3f000,0x0000ffff91f3d000],  sp=0x0000ffff91f3b0b0,  free space=2032k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x90e4f8]  CompressedKlassPointers::reserve_address_space_for_compressed_classes(unsigned long, bool, bool)+0x1f8  (compressedKlass_aarch64.cpp:70)
V  [libjvm.so+0x121311c]  Metaspace::reserve_address_space_for_compressed_classes(unsigned long, bool)+0x2c  (metaspace.cpp:585)
V  [libjvm.so+0x121af50]  MetaspaceShared::reserve_address_space_for_archives(FileMapInfo*, FileMapInfo*, bool, ReservedSpace&, ReservedSpace&, ReservedSpace&)+0x3f0  (metaspaceShared.cpp:1343)
V  [libjvm.so+0x121d250]  MetaspaceShared::map_archives(FileMapInfo*, FileMapInfo*, bool)+0x90  (metaspaceShared.cpp:1050)
V  [libjvm.so+0x121da84]  MetaspaceShared::initialize_runtime_shared_and_meta_spaces()+0x234  (metaspaceShared.cpp:936)
V  [libjvm.so+0x1213540]  Metaspace::global_initialize()+0x130  (metaspace.cpp:714)
V  [libjvm.so+0x15ee0e4]  universe_init()+0x104  (universe.cpp:859)
V  [libjvm.so+0xccffbc]  init_globals()+0x5c  (init.cpp:128)
V  [libjvm.so+0x15be398]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x2c8  (threads.cpp:553)
V  [libjvm.so+0xe3b628]  JNI_CreateJavaVM+0x78  (jni.cpp:3581)
C  [libjli.so+0x3ee0]  JavaMain+0x80  (java.c:1550)
C  [libjli.so+0x78dc]  ThreadJavaMain+0xc  (java_md.c:650)
C  [libpthread.so.0+0x7928]  start_thread+0x188
Comments
[jdk22u-fix-request] Approval Request from Thomas Stuefe This fixes a bug that can, under very rare conditions, cause crashes on VM startup on aarch64. The fix is risk-free and very simple.
11-04-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk22u/pull/139 Date: 2024-04-11 05:47:28 +0000
11-04-2024

Changeset: d9c84e76 Author: Thomas Stuefe <stuefe@openjdk.org> Date: 2024-04-11 05:24:33 +0000 URL: https://git.openjdk.org/jdk/commit/d9c84e763a0880d33586dbb8dc90b66ede030444
11-04-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/18698 Date: 2024-04-09 15:06:40 +0000
09-04-2024

May cause rare intermittent crashes in product jvms, since we may access invalid memory. Raising this to P3.
09-04-2024

> It seems at line 68, the calculation (start_index + ntry + alt_index) would exceed the max value of index (2,147,483,647). > 68 const int index = (start_index + ntry + alt_index) % num_immediates Should we use long types instead for index ?
09-04-2024

[~ccheung] Thanks for investigating. I think the result of os::next_random should be capped (with mod) to [0, num_immediates). I'll fix it.
09-04-2024

Using gdb to inspect the core dump: #34 0x0000ffff9292d500 in reserve_at_eor_compatible_address (aslr=true, size=1090519040) at workspace/open/src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp:70 (gdb) list 65 // addresses; this maximizes the chance of early success if part of the address space 66 // is not accessible (e.g. 39-bit address space). 67 const int alt_index = (ntry & 1) ? 0 : num_immediates / 2; 68 const int index = (start_index + ntry + alt_index) % num_immediates; 69 const uint64_t immediate = ((uint64_t)immediates[index]) << 32; 70 assert(immediate > 0 && Assembler::operand_valid_for_logical_immediate(/*is32*/false, immediate), 71 "Invalid immediate %d " UINT64_FORMAT, index, immediate); 72 result = os::attempt_reserve_memory_at((char*)immediate, size, false); 73 if (result == nullptr) { 74 log_trace(metaspace, map)("Failed to attach at " UINT64_FORMAT_X, immediate); (gdb) print immediate $1 = 0 (gdb) print index $2 = -5 (gdb) print alt_index $3 = 60 (gdb) print ntry $4 = 0 (gdb) print num_immediates $5 = <optimized out> (gdb) print start_index $6 = 2147483591 It seems at line 68, the calculation (start_index + ntry + alt_index) would exceed the max value of index (2,147,483,647). 68 const int index = (start_index + ntry + alt_index) % num_immediates;
08-04-2024

We saw this assertion too, was triggered by vmTestbase/nsk/jvmti/scenarios/hotswap/HS101/hs101t006/TestDescription.java (also on Linux aarch64) # Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-dev-linux_aarch64-dbg/jdk/src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp:70), pid=13501, tid=13504 # assert(immediate > 0 && Assembler::operand_valid_for_logical_immediate( false, immediate)) failed: Invalid immediate -79 0 # # JRE version: (23.0) (fastdebug build ) Stack: [0x0000ffff89762000,0x0000ffff89962000], sp=0x0000ffff899600e0, free space=2040k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x94a770] CompressedKlassPointers::reserve_address_space_for_compressed_classes(unsigned long, bool, bool)+0x260 (compressedKlass_aarch64.cpp:70) V [libjvm.so+0x1279a70] Metaspace::reserve_address_space_for_compressed_classes(unsigned long, bool)+0x2c (metaspace.cpp:585) V [libjvm.so+0x12816ac] MetaspaceShared::reserve_address_space_for_archives(FileMapInfo*, FileMapInfo*, bool, ReservedSpace&, ReservedSpace&, ReservedSpace&)+0x21c (metaspaceShared.cpp:1343) V [libjvm.so+0x12836b0] MetaspaceShared::map_archives(FileMapInfo*, FileMapInfo*, bool)+0x90 (metaspaceShared.cpp:1050) V [libjvm.so+0x1283ec8] MetaspaceShared::initialize_runtime_shared_and_meta_spaces()+0x1e8 (metaspaceShared.cpp:936) V [libjvm.so+0x127a0c4] Metaspace::global_initialize()+0x384 (metaspace.cpp:714) V [libjvm.so+0x1790bf8] universe_init()+0x108 (universe.cpp:859) V [libjvm.so+0xd2699c] init_globals()+0x5c (init.cpp:128) V [libjvm.so+0x175ed44] Threads::create_vm(JavaVMInitArgs*, bool*)+0x2d4 (threads.cpp:553) V [libjvm.so+0xe9356c] JNI_CreateJavaVM+0x78 (jni.cpp:3581) C [libjli.so+0x3f4c] JavaMain+0x7c (java.c:1550) C [libjli.so+0x77fc] ThreadJavaMain+0xc (java_md.c:650) C [libpthread.so.0+0x8748] start_thread+0x188
08-04-2024

[~stuefe] Does this look familiar to you?
04-04-2024