JDK-8355396 : Internal Error when running gc/TestAllocHumongousFragment.java#generational - Error: Before Full GC, Reachable; Object start should be within the region
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 25
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: linux
  • CPU: ppc
  • Submitted: 2025-04-23
  • Updated: 2025-06-23
Related Reports
Relates :  
Relates :  
Description
When running jtreg test gc/TestAllocHumongousFragment.java#generational , the following Internal error was triggered :

#  Internal Error (shenandoahVerifier.cpp:110), pid=68218, tid=68234
#  Error: Before Full GC, Reachable; Object start should be within the region

Referenced from:
  interior location: 0x00000000c067b9fc
  0x00000000c067b9e8 - klass 0x000002ae00170dd0 [Ljava.lang.Object;
        allocated after mark start
    not after update watermark
        marked strong
        marked weak
    not in collection set
  age: 0
  mark: mark(is_unlocked no_hash age=0)
  region: |   12|R  |O|BTE     c0600000,     c067ba80,     c0680000|TAMS     c0600000|UWM     c067ba80|U   494K|T     0B|G     0B|P     0B|S   494K|L   494K|CP   0

Object:
  0x00000000fc900000 - safe print, no details
  region: | 1938|EC |F|BTE     fc900000,     fc900000,     fc980000|TAMS     fc900000|UWM     fc900000|U     0B|T     0B|G     0B|P     0B|S     0B|L     0B|CP   0

Raw heap memory:
0x00000000fc900000:   00000001 00000000 00172210 0019bb53   ........."..S...
0x00000000fc900010:   00000000 00000000 00000000 00000000   ................
0x00000000fc900020:   00000000 00000000 00000000 00000000   ................
0x00000000fc900030:   00000000 00000000 00000000 00000000   ................
0x00000000fc900040:   00000000 00000000 00000000 00000000   ................
0x00000000fc900050:   00000000 00000000 00000000 00000000   ................
0x00000000fc900060:   00000000 00000000 00000000 00000000   ................
0x00000000fc900070:   00000000 00000000 00000000 00000000   ................

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x122be08]  VMError::report(outputStream*, bool)+0x28a8  (shenandoahVerifier.cpp:110)
V  [libjvm.so+0x1230b78]  VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x428  (vmError.cpp:1825)
V  [libjvm.so+0x673c8c]  report_vm_error(char const*, int, char const*, char const*, ...)+0xdc  (debug.cpp:196)
V  [libjvm.so+0x673ce0]  report_vm_error(char const*, int, char const*)+0x30  (debug.cpp:149)
V  [libjvm.so+0xf503e0]  ShenandoahAsserts::print_failure(ShenandoahAsserts::SafeLevel, oopDesc*, void*, oopDesc*, char const*, char const*, char const*, int)+0x220  (shenandoahAsserts.cpp:168)
V  [libjvm.so+0x105c058]  ShenandoahVerifyOopClosure::verify_oop(oopDesc*)+0x618  (shenandoahVerifier.cpp:110)
V  [libjvm.so+0x1063bd0]  void OopOopIterateDispatch<ShenandoahVerifyOopClosure>::Table::oop_oop_iterate<ObjArrayKlass, narrowOop>(ShenandoahVerifyOopClosure*, oopDesc*, Klass*)+0x370  (shenandoahVerifier.cpp:332)
V  [libjvm.so+0x105e160]  ShenandoahVerifierReachableTask::work(unsigned int)+0x320  (iterator.inline.hpp:300)
V  [libjvm.so+0x1278014]  WorkerThread::run()+0xe4  (workerThread.cpp:69)
V  [libjvm.so+0x116ae1c]  Thread::call_run()+0xec  (thread.cpp:231)
V  [libjvm.so+0xe15040]  thread_native_entry(Thread*)+0x130  (os_linux.cpp:875)
C  [libc.so.6+0xb2014]  start_thread+0x184

The issue was seen on Linux ppc64le.  On Linux x86_64 we saw no such crash but quite a few timeouts when running this test.

Comments
Both crash logs show an active old region holding a pointer to an object which putatively is the start of an empty free region. Presumably, the pointer in the active old generation is bogus, or the verification is somehow looking at an object in the old generation that is dead? Note that in both cases, the verification is in the "Before Full GC" phase, and claims that the object is reachable. I'll examine what the pre-full-gc verification pass is checking here. It _could_ also indicate that somehow the card-marking of the old generation is incorrect and the reference failed to be preserved in a previous (young) gc cycle.
23-06-2025

Hi [~ysr] I added two hserr one from the reported occurrence , and one from another. Seems we had one in April , one in May so far, both running jdk25 .
11-06-2025

[~mbaesken], could you attach the entire hs_err file and gc log file for this crash to the ticket please? Thanks!
10-06-2025

Seems this one https://bugs.openjdk.org/browse/JDK-8282844 was a little bit similar.
23-04-2025