JDK-8345181 : fatal error in Concurrent HashTable: Cannot resize table: Node hash code has changed possibly due to corruption of the contents.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 24
  • Priority: P4
  • Status: New
  • Resolution: Unresolved
  • OS: windows
  • CPU: x86_64
  • Submitted: 2024-11-28
  • Updated: 2024-11-29
Description
The test jdk/java/text/Format/NumberFormat/NumberTest.java crashed on Windows-x64 with

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (utilities/concurrentHashTable.inline.hpp:684), pid=78164, tid=39652
#  fatal error: Cannot resize table: Node hash code has changed possibly due to corruption of the contents.
#
# JRE version: Java(TM) SE Runtime Environment (24.0+26) (build 24-ea+26-3343)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24-ea+26-3343, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# V  [jvm.dll+0x7cc3bf]  ConcurrentHashTable<StringTableConfig,11>::unzip_bucket+0x2bf
#
# Core dump will be written. Default location: C:\sb\prod\1732782350\testoutput\test-support\jtreg_open_test_jdk_tier2_part2\scratch\4\hs_err_pid78164.mdmp
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -Xmx768m -XX:MaxRAMPercentage=4.16667 -Dtest.boot.jdk=c:\ade\mesos\work_dir\jib-master\install\jdk\23\37\bundles\windows-x64\jdk-23_windows-x64_bin.zip\jdk-23 -Djava.io.tmpdir=c:\sb\prod\1732782350\testoutput\test-support\jtreg_open_test_jdk_tier2_part2\tmp -XX:+CreateCoredumpOnCrash -ea -esa -Djava.library.path=c:\ade\mesos\work_dir\jib-master\install\jdk-24+26-3343\windows-x64.test\jdk\jtreg\native --patch-module=java.base=C:\sb\prod\1732782350\testoutput\test-support\jtreg_open_test_jdk_tier2_part2\patches\java.base -Djava.security.policy=file:/c:/sb/prod/1732782350/testoutput/test-support/jtreg_open_test_jdk_tier2_part2/jtreg.policy com.sun.javatest.regtest.agent.AgentServer -id 24 -logfile C:\sb\prod\1732782350\testoutput\test-support\jtreg_open_test_jdk_tier2_part2\jtData\agentServer.24.trace -allowSetSecurityManager -port 59001 -timeoutFactor 4.0

Host: Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz, 12 cores, 23G,  Windows Server 2022 , 64 bit Build 20348 (10.0.20348.2760)
Time: Thu Nov 28 08:37:46 2024 Etc elapsed time: 169.884576 seconds (0d 0h 2m 49s)

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

Current thread (0x00000280b1e69530):  JavaThread "Service Thread" daemon [_thread_in_vm, id=39652, stack(0x000000e994d00000,0x000000e994e00000) (1024K)]

Stack: [0x000000e994d00000,0x000000e994e00000],  sp=0x000000e994dff5f0,  free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x7cc3bf]  ConcurrentHashTable<StringTableConfig,11>::unzip_bucket+0x2bf  (concurrentHashTable.inline.hpp:684)
V  [jvm.dll+0x7caafa]  StringTable::grow+0x23a  (stringTable.cpp:575)
V  [jvm.dll+0x7c9a4f]  StringTable::do_concurrent_work+0x12f  (stringTable.cpp:673)
V  [jvm.dll+0x79f5e3]  ServiceThread::service_thread_entry+0x1e3  (serviceThread.cpp:135)
V  [jvm.dll+0x42ed06]  JavaThread::run+0x116  (javaThread.cpp:757)
V  [jvm.dll+0x87ca1b]  Thread::call_run+0xcb  (thread.cpp:242)
V  [jvm.dll+0x72e215]  thread_native_entry+0x95  (os_windows.cpp:545)
C  [ucrtbase.dll+0x26b4c]  (no source info available)
C  [KERNEL32.DLL+0x14cb0]  (no source info available)
C  [ntdll.dll+0x7ecdb]  (no source info available)
Comments
This appears to be the corrupt string that is being reported: stack at sp + 2 slots: 0x00000000d7c308f0 is an oop: java.lang.String {0x00000000d7c308f0} - klass: 'java/lang/String' - flags: - string: "�ܻܱ���" - ---- fields (total size 3 words): - private 'hash' 'I' @12 0 (0x00000000) - private final 'coder' 'B' @16 1 (0x01) - private 'hashIsZero' 'Z' @17 false (0x00) - injected 'flags' 'B' @18 0 (0x00) - private final 'value' '[B' @20 [B{0x00000000d7c30908} (0xd7c30908) CORRECTION: the above doesn't necessarily indicate corruption, the string is non-ascii so can't be printed in the log.
29-11-2024
A related test also failed on Windows: java/text/Format/DateFormat/bug4117335.java This time the failure was more obscure and possibly unrelated: ----------System.out:(2/104)*---------- BC = \u00e7\u00b4\u20ac\u00e5\u2026\u0192\u00e5\u2030\ufffd AD = \u00e8\u00a5\u00bf\u00e6\u0161\u00a6 result: Error. Agent communication error: java.net.SocketException: Connection reset; check console log for any additional details But seems somewhat of a coincidence.
29-11-2024
Same test also crashed with # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffb4a8fcfb0, pid=5656, tid=32576 # # JRE version: Java(TM) SE Runtime Environment (24.0+27) (build 24-ea+27-3360) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24-ea+27-3360, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) # Problematic frame: # V [jvm.dll+0xcfb0] AccessInternal::PostRuntimeDispatch<EpsilonBarrierSet::AccessBarrier<548964,EpsilonBarrierSet>,2,548964>::oop_access_barrier+0x0 # and hs_err file shows the stringtable is still involved Stack slot to memory mapping: stack at sp + 0 slots: 0x00007ffb4b0b802f jvm.dll::ConcurrentHashTable<StringTableConfig,11>::get<StringTableLookupUTF8,StringTableGet> + 0xaf stack at sp + 1 slots: 0x0000020d097d3460 points into unknown readable memory: 0x0000020d065fa520 | 20 a5 5f 06 0d 02 00 00 stack at sp + 2 slots: 0x0 is null stack at sp + 3 slots: 0x0000020d053f7f50 is a thread stack at sp + 4 slots: 0x00007ffb4b0b9a01 jvm.dll::StringTable::do_intern + 0x171 stack at sp + 5 slots: 0x000000c5735fbfd0 is pointing into the stack for thread: 0x0000020d053f7f50 stack at sp + 6 slots: 0x0000000031361e2e is pointing into metadata stack at sp + 7 slots: 0x0000020d053f7f50 is a thread
28-11-2024
Seen only once so far in Oracle CI. The most recent commit was JDK-8345119. Not obviously related, as that is a test-only change. One of the tests is othervm, so not related. The other, and the failing test, are run in agentvm.
28-11-2024