JDK-8299658 : C1 compilation crashes in LinearScan::resolve_exception_edge
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u172,11,17,21,22
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • CPU: x86_64
  • Submitted: 2023-01-02
  • Updated: 2023-10-19
  • Resolved: 2023-08-28
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 11 JDK 17 JDK 21 JDK 22
11.0.21Fixed 17.0.10-oracleFixed 21.0.1Fixed 22 b13Fixed
Related Reports
Relates :  
JDK-8214352 - C1: Unnecessary "compilation bailout: block join failed" with JVMTI
Relates :  
JDK-8151818 - C1: LIRGenerator::move_to_phi can't deal with illegal phi
Description
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f604221467f, pid=596545, tid=596560
#
# JRE version: Java(TM) SE Runtime Environment (22.0+8) (fastdebug build 22-ea+8-534)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-ea+8-534, mixed mode, sharing, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x7e867f]  LinearScan::resolve_exception_edge(XHandler*, int, int, Phi*, MoveResolver&) [clone .part.0]+0x6f

Current CompileTask:
C1:   1395  137   !b  3       AbstractDecoratingResourcePoolKt::readHttpBody (888 bytes)

Stack: [0x00007f6018d6b000,0x00007f6018e6c000],  sp=0x00007f6018e695c0,  free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x7e867f]  LinearScan::resolve_exception_edge(XHandler*, int, int, Phi*, MoveResolver&) [clone .part.0]+0x6f
V  [libjvm.so+0x7e948c]  LinearScan::resolve_exception_edge(XHandler*, int, MoveResolver&)+0x47c
V  [libjvm.so+0x7eb30e]  LinearScan::resolve_exception_handlers()+0x29e
V  [libjvm.so+0x7ec48e]  LinearScan::do_linear_scan()+0x31e
V  [libjvm.so+0x727fc6]  Compilation::emit_lir()+0x966
V  [libjvm.so+0x72a407]  Compilation::compile_java_method()+0x247
V  [libjvm.so+0x72adbb]  Compilation::compile_method()+0x14b
V  [libjvm.so+0x72b564]  Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x2b4
V  [libjvm.so+0x72cfde]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xde
V  [libjvm.so+0x9f9530]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa00
V  [libjvm.so+0x9fa3b8]  CompileBroker::compiler_thread_loop()+0x618
V  [libjvm.so+0xeb457c]  JavaThread::thread_main_inner()+0xcc
V  [libjvm.so+0x17952da]  Thread::call_run()+0xba
V  [libjvm.so+0x1495dd1]  thread_native_entry(Thread*)+0x121
Comments
Fix Request (11u): Same as for 21u and 17u except that it requires a trivial adaptation (reviewed in PR).
06-09-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u/pull/82 Date: 2023-09-05 16:42:05 +0000
05-09-2023
[~aoubidar] Thanks! The fix is in JDK 22 b13. Builds can be found here: https://jdk.java.net/22/
04-09-2023
[~thartmann] Sure, could you please share with me a link to the dev build of OpenJDK containing the fix? I'll make sure to share it with the user.
04-09-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u/pull/378 Date: 2023-09-01 09:16:29 +0000
01-09-2023
Thanks for the feedback! I've started backporting. [~aoubidar] It would really be great if you could verify the fix with the original workload. It's resolved in JDK22 with build b13.
01-09-2023
> We are shipping the fix with the next EA build. Would be great if it could be verified with the original workload. Is there a need for a backport in any LTS OpenJDK release for that? [~mdoerr], the original reporter of this bug is unresponsive but maybe the submitter of the new report (https://github.com/oracle/graal/issues/6994) could verify. [~aoubidar], could you reach out to him? > [~thartmann] Backporting doesn't really have any risk. We only handle a case in which the VM would crash without the fix. Do you think I should start backporting it right now? Sounds reasonable to me.
01-09-2023
Fix Request (21u, 17u): 21 and 17 are affected by this bug. The VM may crash without the fix. Applies cleanly. Risk: Very low because we only catch "from_value == nullptr" and avoid an immediate crash by nullptr dereferencing.
31-08-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/1716 Date: 2023-08-31 19:19:35 +0000
31-08-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u/pull/119 Date: 2023-08-31 19:15:15 +0000
31-08-2023
I think it makes sense to backport. As you said, without a fix we would crash the compiler, since the `nullptr` `from_value` that new code checks would be dereferenced in the old code very soon.
30-08-2023
We are shipping the fix with the next EA build. Would be great if it could be verified with the original workload. Is there a need for a backport in any LTS OpenJDK release for that? [~thartmann] Backporting doesn't really have any risk. We only handle a case in which the VM would crash without the fix. Do you think I should start backporting it right now?
28-08-2023
Changeset: cf2d33ca Author: Martin Doerr <mdoerr@openjdk.org> Date: 2023-08-28 10:14:19 +0000 URL: https://git.openjdk.org/jdk/commit/cf2d33ca2ee08c61596ab10b7602500a6931fa31
28-08-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/15348 Date: 2023-08-18 20:17:52 +0000
18-08-2023
I've published a possible solution: https://github.com/openjdk/jdk/pull/15348 If somebody finds a better solution, I'll be glad to close it. A regression test would be really good, but I don't think I can get that done within a reasonable amount of time. I'll appreciate any help in this regard.
18-08-2023
Right, I thought that maybe there's a way to propagate the "illegal" state from the a693 phi to the a678 phi but couldn't figure it out from skimming through the code. Do you have time to take this bug or should we assign to someone else? Would also be good to have a regression test for this.
18-08-2023
Thanks for analyzing it! Ideally, the phi should get invalidated (make_illegal). Seems like this does not work by the normal way because exception edges are treated differently. A quick workaround would be "if (from_value == nullptr) return;". We already skip unused phi functions, too.
17-08-2023
We crash because operand 6 of phi a678 is null but a678 is not marked as illegal: __bci__use__tid____instr____________________________________ . 852 0 1 B1 (EbV) [852, 1] -> B144 B143 dom B5 pred: B47 B137 B46 B43 Locals: 0 a670 [ a640 a640 a640 a640 a657 a657 a685 a685 a685 a685 a685 a685 a685 a685] 1 a671 [ a49 a49 a49 a49 a658 a658 a686 a686 a686 a686 a686 a686 a686 a686] 2 a672 [ a50 a50 a50 a50 a659 a659 a687 a687 a687 a687 a687 a687 a687 a687] 4 a673 [ a638 a638 a638 a638 a660 a660 a688 a688 a688 a688 a688 a688 a688 a688] 6 i674 [ i52 i52 i52 i52 i661 i661 i689 i689 i689 i689 i689 i689 i689 i689] 7 a675 [ a636 a636 a636 a636 a662 a662 a690 a690 a690 a690 a690 a690 a690 a690] 8 a676 [ a634 a634 a634 a634 a663 a663 a691 a691 a691 a691 a691 a691 a691 a691] 9 i677 [ i52 i52 i52 i52 i664 i664 i692 i692 i692 i692 i692 i692 i692 i692] 10 a678 [ a632 a632 a632 a632 a665 a665 null a697 a697 a697 a697 a697 a697 a697] 14 a679 [ a70 a70 a70 a70 a666 a666 a694 a694 a694 a694 a694 a694 a694 a694] 15 a680 [ a69 a69 a69 a69 a667 a667 a695 a695 a695 a695 a695 a695 a695 a695] 16 a681 [ a76 a76 a76 a76 a668 a668 a696 a696 a696 a696 a696 a696 a696 a696] Earlier state: B1 (EbV) [852, 1] -> B144 B143 dom B5 pred: B47 B137 B46 B43 Locals: 0 a670 [ a640 a640 a640 a640 a657 a657 a685 a685 a685 a685 a685 a685 a685 a685] 1 a671 [ a49 a49 a49 a49 a658 a658 a686 a686 a686 a686 a686 a686 a686 a686] 2 a672 [ a50 a50 a50 a50 a659 a659 a687 a687 a687 a687 a687 a687 a687 a687] 4 a673 [ a638 a638 a638 a638 a660 a660 a688 a688 a688 a688 a688 a688 a688 a688] 6 i674 [ i52 i52 i52 i52 i661 i661 i689 i689 i689 i689 i689 i689 i689 i689] 7 a675 [ a636 a636 a636 a636 a662 a662 a690 a690 a690 a690 a690 a690 a690 a690] 8 a676 [ a634 a634 a634 a634 a663 a663 a691 a691 a691 a691 a691 a691 a691 a691] 9 i677 [ i52 i52 i52 i52 i664 i664 i692 i692 i692 i692 i692 i692 i692 i692] 10 a678 [ a632 a632 a632 a632 a665 a665 693 a697 a697 a697 a697 a697 a697 a697] 14 a679 [ a70 a70 a70 a70 a666 a666 a694 a694 a694 a694 a694 a694 a694 a694] 15 a680 [ a69 a69 a69 a69 a667 a667 a695 a695 a695 a695 a695 a695 a695 a695] 16 a681 [ a76 a76 a76 a76 a668 a668 a696 a696 a696 a696 a696 a696 a696 a696] 'LIRGenerator::state_for then' calls 'invalidate_local' because local 10 has value->type()->is_illegal() set. This comes from the code added by JDK-8214352: https://hg.openjdk.org/jdk/jdk/rev/b3830528df29#l1.17 I think the original report with JDK 8u172 is actually a duplicate of JDK-8151818 which was fixed in JDK 9 and the new report is a regression from JDK-8214352. ILW = Crash during C1 compilation, rare but reproducible with Kotlin and JVMTI (JvmtiExport can_access_local_variables 1), no workaround but disable compilation of affected method = HLM = P3 [~mdoerr], could you please have a look?
16-08-2023
To reproduce run the following command with attached AbstractDecoratingResourcePoolKt.class and https://mvnrepository.com/artifact/org.jetbrains.kotlin/kotlin-stdlib/1.9.0 on the classpath: java -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler -XX:+ReplayIgnoreInitErrors -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid434227.log -cp kotlin-stdlib-1.9.0.jar:.
15-08-2023
There is no response from submitter, closing this as incomplete. This can be reopened if we receive any information in future.
16-01-2023
additional information requested: ================================ To understand the issue better, could you please provide a standalone test case or steps to reproduce this issue? Also, this crash is reported in JDK 8u172 which is very old, it is recommended that you test this issue in the latest JDK and share results. https://www.oracle.com/java/technologies/downloads/#java8 ================================
05-01-2023