JDK-8332903 : ubsan: opto/output.cpp:1002:18: runtime error: load of value 171, which is not a valid value for type 'bool'
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,21,23
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: ppc
  • Submitted: 2024-05-24
  • Updated: 2024-08-28
  • Resolved: 2024-06-17
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 17 JDK 21 JDK 23 JDK 24
17.0.14Fixed 21.0.5Fixed 23.0.2Fixed 24 b03Fixed
Related Reports
Relates :  
JDK-8334560 - [PPC64]: postalloc_expand_java_dynamic_call_sched does not copy all fields
Relates :  
JDK-8227745 - Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Relates :  
JDK-8334303 - Create common method to initialize MachCallJavaNode fields
Description
When building with ubsan on linuxppc64le  we run into the issue below;  seems some initialization is missing.
 
/jdk/src/hotspot/share/opto/output.cpp:1002:18: runtime error: load of value 171, which is not a valid value for type 'bool'
    #0 0x7fff8f52b71c in PhaseOutput::Process_OopMap_Node(MachNode*, int) (/jdk/lib/server/libjvm.so+0x74cb71c)
    #1 0x7fff8f530ab4 in PhaseOutput::fill_buffer(C2_MacroAssembler*, unsigned int*) (/jdk/lib/server/libjvm.so+0x74d0ab4)
    #2 0x7fff8f53c740 in PhaseOutput::Output() (/jdk/lib/server/libjvm.so+0x74dc740)
    #3 0x7fff8d5b6350 in Compile::Code_Gen() (/jdk/lib/server/libjvm.so+0x5556350)
    #4 0x7fff8d5be730 in Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*) (/jdk/lib/server/libjvm.so+0x555e730)
    #5 0x7fff8cfe7434 in C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*) (/jdk/lib/server/libjvm.so+0x4f87434)
    #6 0x7fff8d5e3bf4 in CompileBroker::invoke_compiler_on_method(CompileTask*) (/jdk/lib/server/libjvm.so+0x5583bf4)
    #7 0x7fff8d5e5a74 in CompileBroker::compiler_thread_loop() (/jdk/lib/server/libjvm.so+0x5585a74)
    #8 0x7fff8d6403c0 in CompilerThread::thread_entry(JavaThread*, JavaThread*) (/jdk/lib/server/libjvm.so+0x55e03c0)
    #9 0x7fff8e428810 in JavaThread::thread_main_inner() (/jdk/lib/server/libjvm.so+0x63c8810)
    #10 0x7fff900992e8 in Thread::call_run() (/jdk/lib/server/libjvm.so+0x80392e8)
    #11 0x7fff8f4a6a08 in thread_native_entry(Thread*) (/jdk/lib/server/libjvm.so+0x7446a08)
    #12 0x7fff95139714 in start_thread (/lib64/libpthread.so.0+0x9714)
    #13 0x7fff944eb774 in __GI___clone (/lib64/libc.so.6+0x13b774)
   ... (rest of output omitted)
Comments
jdk17u-dev backport request I would like to have the patch in jdk17u-dev as well, because the issue is present there too. The backport is clean and low risk.
14-08-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk17u-dev/pull/2805 Date: 2024-08-14 11:55:06 +0000
14-08-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk21u-dev/pull/872 Date: 2024-07-29 07:10:43 +0000
29-07-2024
jdk21u-dev backport request I would like to have the patch in jdk21u-dev as well, because the issue is present there too. The backport is clean and low risk.
29-07-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk23u/pull/35 Date: 2024-07-25 14:59:18 +0000
25-07-2024
jdk23u backport request I would like to have the patch in jdk23u as well, because the issue is present there too. The backport is clean and low risk.
25-07-2024
Changeset: 113a2c02 Author: Matthias Baesken <mbaesken@openjdk.org> Date: 2024-06-17 08:57:57 +0000 URL: https://git.openjdk.org/jdk/commit/113a2c028dc3b9abb6229d5f0b812b54a9b61011
17-06-2024
Great, let's mark this as ppc specific then.
14-06-2024
> [~mbaesken] I think we need to figure out why this only seems to affect ppc to make sure we don't miss anything. [~reinrich] pointed out that the ppc.ad file needed a small adjustment. This explains why the issue was not seen on x86_64 .
14-06-2024
[~mbaesken] I think we need to figure out why this only seems to affect ppc to make sure we don't miss anything.
13-06-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/19677 Date: 2024-06-12 13:47:25 +0000
12-06-2024
> With an added initialization of _arg_escape the issue does not occur. Not sure why I see it only on Linux ppc64le but so far not on x86_64 . Hi Tobias and [~mdoerr] should I do this patch ? Or do you have something better in mind ? I never saw this issue on x86_64 , only ppc64le so far. Not sure why but I did quite a lot of ubsan builds/runs in the last weeks .
12-06-2024
Removing CPU=ppc for now as this does not seem to be ppc specific. ILW = Uninitialized boolean field potentially leading to undefined behavior, error found with ubsan; never observed an issue, no workaround = MLH = P4
27-05-2024
I think Matcher::match_sfpt is supposed to initialize the fields, not sure why it didn't happen in this case.
27-05-2024
Looks like there are some more fields that should potentially be initialized in the MachCallJavaNode constructor but _arg_escape was added by JDK-8227745.
27-05-2024
With an added initialization of _arg_escape the issue does not occur. Not sure why I see it only on Linux ppc64le but so far not on x86_64 . diff --git a/src/hotspot/share/opto/machnode.hpp b/src/hotspot/share/opto/machnode.hpp index 677e1bcd1d1..3c4f8adb8c3 100644 --- a/src/hotspot/share/opto/machnode.hpp +++ b/src/hotspot/share/opto/machnode.hpp @@ -940,7 +940,7 @@ class MachCallJavaNode : public MachCallNode { bool _optimized_virtual; // Tells if node is a static call or an optimized virtual bool _method_handle_invoke; // Tells if the call has to preserve SP bool _arg_escape; // ArgEscape in parameter list - MachCallJavaNode() : MachCallNode(), _override_symbolic_info(false) { + MachCallJavaNode() : MachCallNode(), _override_symbolic_info(false), _arg_escape(false) { init_class_id(Class_MachCallJava); }
24-05-2024