JDK-8312134 : assert(in_hash) failed: node should be in igvn hash table
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 22
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2023-07-16
  • Updated: 2024-05-20
  • Resolved: 2024-05-20
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.
Other
tbdResolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
Test: tools/jpackage/share/jdk/jpackage/tests/JavaOptionsTest.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/cd627e65-f015-4fb1-a1d2-b6c9b8127f98-S74882/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ec70f7f4-26ce-499f-9c7f-b48b197a7bbc/runs/cb4ccd5e-c255-4e79-adca-3e07e920c64b/workspace/open/src/hotspot/share/opto/compile.cpp:4902), pid=1075210, tid=1075225
#  assert(in_hash) failed: node should be in igvn hash table
#
# JRE version: Java(TM) SE Runtime Environment (22.0+7) (fastdebug build 22-ea+7-396)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-ea+7-396, mixed mode, sharing, compressed oops, compressed class ptrs, parallel gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x9d5fa2][17:17:21.419] TRACE: Bundler rpm supported
  Compile::remove_speculative_types(PhaseIterGVN&) [clone .part.0]+0xab2
Comments
Correct, the error occurred before JDK-8321204 was pushed.
20-05-2024

It does look like a duplicate of JDK-8321204.
15-05-2024

[~mdoerr] JDK-8321204 fixed the intermittent issues around the hash table entries and removed the graph dumping code. So, since you're showing the dumped graph, I assume the report is from a version before having the fix for JDK-8321204. Can you confirm that?
15-05-2024

I've reopened the issue after we got the debug information from JDK-8312218 in sun/security/krb5/auto/BasicKrb5Test.java: current graph: 0 Root === 0 43 240 263 277 345 4556 529 3549 767 4142 4153 4164 5492 5158 4199 5141 4976 4961 4938 4762 4752 4742 4214 4332 4363 4539 |4511 5115 [[ 0 1 3 23 24 28 38 5059 58 5025 4995 75 4924 124 4917 4869 4835 4524 4514 4513 4462 4345 4263 4232 4194 4185 4159 216 235 242 245 247 4148 250 258 272 4137 281 4120 3872 348 596 599 847 850 851 1099 1102 1103 1353 1354 1602 1605 1606 1854 1857 2105 2108 2356 2359 2360 2608 2611 2612 2860 2863 2864 3112 3115 3116 3364 3367 3368 3616 3619 3620 3868 3871 5525 5606 5610 5617 5624 5634 5639 5655 5671 5677 5684 5694 5700 5710 5716 5726 5732 5742 5748 5758 5764 5775 5781 5790 5800 5806 5816 5822 5828 5838 5844 5849 5855 5856 5859 5860 5863 5864 5867 5868 5871 5872 5875 5878 5881 5884 5885 5886 5887 5888 5889 5890 5891 5892 5893 5894 5895 5896 5899 5902 5905 5906 5909 5912 5913 5929 5958 5962 ]] 3 Start === 3 0 [[ 3 5 6 7 8 9 10 11 12 ]] #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:sun/security/provider/SHA5$SHA384 (java/lang/Cloneable):NotNull:exact *, 6:byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact *, 7:int} 5 Parm === 3 [[ 31 ]] Control !jvms: SHA5::implCompress0 @ bci:-1 (line 243) 7 Parm === 3 [[ 5144 4964 4542 4202 26 4157 39 4146 4135 4756 1059 4080 4530 341 4952 3828 1562 306 1311 3576 3542 18 5116 3324 4746 4736 331 3072 4189 807 4325 2820 5119 4969 4356 2568 522 758 4207 2316 5151 347 4931 236 2065 244 5132 259 556 4512 273 1814 5128 4549 4516 ]] Memory Memory: @BotPTR *+bot, idx=Bot; !orig=[4168],[4173],[4766],[4779] !jvms: SHA5::implCompress0 @ bci:-1 (line 243) 10 Parm === 3 [[ 4525 4149 39 25 25 4138 4511 4934 5154 259 273 341 4359 525 4972 763 4525 4328 4748 4758 4738 4210 4552 3545 4160 5115 ]] Parm0: sun/security/provider/SHA5$SHA384 (java/lang/Cloneable):NotNull:exact * Oop:sun/security/provider/SHA5$SHA384 (java/lang/Cloneable):NotNull:exact * !jvms: SHA5::implCompress0 @ bci:-1 (line 243) 11 Parm === 3 [[ 60 39 ]] Parm1: byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact * !jvms: SHA5::implCompress0 @ bci:-1 (line 243) 23 ConL === 0 [[ 25 5341 1351 4653 1309 ]] #long:48 25 AddP === _ 10 10 23 [[ 26 ]] Oop:sun/security/provider/SHA5$SHA384 (java/lang/Cloneable):NotNull:exact+48 * [narrow] !jvms: SHA5::implCompress0 @ bci:1 (line 243) 26 LoadN === _ 7 25 [[ 27 ]] @sun/security/provider/SHA5 (java/lang/Cloneable)+48 * [narrow], name=W, idx=4; #narrowoop: long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact * !orig=[4948] !jvms: SHA5::implCompress0 @ bci:1 (line 243) 27 DecodeN === _ 26 [[ 39 29 35 273 273 259 259 4200 4962 ]] #long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact * !orig=[4949] !jvms: SHA5::implCompress0 @ bci:1 (line 243) 28 ConP === 0 [[ 29 4195 5137 5130 228 236 4957 4535 ]] #null 29 CmpP === _ 27 28 [[ 30 ]] !orig=[4187] !jvms: SHA5::implCompress0 @ bci:4 (line 243) 30 Bool === _ 29 [[ 31 4954 4191 ]] [ne] !orig=[4951] !jvms: SHA5::implCompress0 @ bci:4 (line 243) 31 If === 5 30 [[ 34 37 ]] P=1.000000, C=3129.000000 !jvms: SHA5::implCompress0 @ bci:4 (line 243) 34 IfTrue === 31 [[ 232 35 60 ]] #1 !jvms: SHA5::implCompress0 @ bci:4 (line 243) 60 CheckCastPP === 34 11 [[ 259 259 273 241 228 273 ]] #byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact * (speculative=byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *) !jvms: ByteArrayAccess::b2lBig128 @ bci:7 (line 148) SHA5::implCompress0 @ bci:21 (line 246) erroneous node: 60 CheckCastPP === 34 11 [[ 259 259 273 241 228 273 ]] #byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact * (speculative=byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *) !jvms: ByteArrayAccess::b2lBig128 @ bci:7 (line 148) SHA5::implCompress0 @ bci:21 (line 246)
15-05-2024

That's a good idea! I've filed JDK-8312218 for that.
18-07-2023

Can we not add some further diagnostics to aid in debugging this?
17-07-2023

Unfortunately, the replay file is empty, the core file did not help either as the stack was corrupted and re-running the failing test did not trigger the assert either. This seems to be a very intermittent and hard to reproduce failure. Hopefully, we'll get another crash at some point where we have more information. I guess we cannot do much more than closing this one yet again as cannot reproduce.
17-07-2023

This failure mode seems to keep recurring but issues get closed as not reproducible - most recently in JDK-8273094.
16-07-2023