JDK-8344026 : Ubsan: prevent potential integer overflow in c1_LIRGenerator_.cpp file
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,17,21,24
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: arm,ppc,aarch64,s390x
  • Submitted: 2024-11-12
  • Updated: 2024-12-25
  • Resolved: 2024-12-12
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 25
25 b03Fixed
Related Reports
Duplicate :  
JDK-8345373 - [s390x] ubsan: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Relates :  
JDK-8181872 - C1: possible overflow when strength reducing integer multiply by constant
Description
while running tier1 test with ubsan enabled, I got failures with same error as below: 

/home/amit/ubsan/jdk/src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp:500:55: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
    #0 0x3ffa9ff997f in LIRGenerator::do_ArithmeticOp_Int(ArithmeticOp*) /home/amit/ubsan/jdk/src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp:500
    #1 0x3ffa9f8514f in LIRGenerator::walk(Instruction*) /home/amit/ubsan/jdk/src/hotspot/share/c1/c1_LIRGenerator.cpp:394
    #2 0x3ffa9ff81db in LIRItem::set_instruction(Instruction*) /home/amit/ubsan/jdk/src/hotspot/share/c1/c1_LIRGenerator.hpp:631
    #3 0x3ffa9ff81db in LIRItem::LIRItem(Instruction*, LIRGenerator*) /home/amit/ubsan/jdk/src/hotspot/share/c1/c1_LIRGenerator.hpp:617
    #4 0x3ffa9ff81db in LIRGenerator::do_ArithmeticOp_Int(ArithmeticOp*) /home/amit/ubsan/jdk/src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp:483
    #5 0x3ffa9f8514f in LIRGenerator::walk(Instruction*) /home/amit/ubsan/jdk/src/hotspot/share/c1/c1_LIRGenerator.cpp:394
    #6 0x3ffa9fc8841 in LIRItem::set_instruction(Instruction*) /home/amit/ubsan/jdk/src/hotspot/share/c1/c1_LIRGenerator.hpp:631
    #7 0x3ffa9fc8841 in LIRItem::LIRItem(Instruction*, LIRGenerator*) /home/amit/ubsan/jdk/src/hotspot/share/c1/c1_LIRGenerator.hpp:617
    #8 0x3ffa9fc8841 in LIRGenerator::do_Return(Return*) /home/amit/ubsan/jdk/src/hotspot/share/c1/c1_LIRGenerator.cpp:1200
    #9 0x3ffa9f84ad3 in LIRGenerator::do_root(Instruction*) /home/amit/ubsan/jdk/src/hotspot/share/c1/c1_LIRGenerator.cpp:379
    #10 0x3ffa9f92bdb in non-virtual thunk to LIRGenerator::block_do(BlockBegin*) (/home/amit/ubsan/jdk/build/linux-s390x-server-fastdebug/images/jdk/lib/server/libjvm.so+0x3d92bdb)
    #11 0x3ffa9ec1d0b in BlockList::iterate_forward(BlockClosure*) /home/amit/ubsan/jdk/src/hotspot/share/c1/c1_Instruction.cpp:891
    #12 0x3ffa9de50f3 in Compilation::emit_lir() /home/amit/ubsan/jdk/src/hotspot/share/c1/c1_Compilation.cpp:264
    #13 0x3ffa9dedae1 in Compilation::compile_java_method() /home/amit/ubsan/jdk/src/hotspot/share/c1/c1_Compilation.cpp:405
    #14 0x3ffa9defe0d in Compilation::compile_method() /home/amit/ubsan/jdk/src/hotspot/share/c1/c1_Compilation.cpp:478
    #15 0x3ffa9df14ab in Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*) /home/amit/ubsan/jdk/src/hotspot/share/c1/c1_Compilation.cpp:608
    #16 0x3ffa9df611b in Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*) /home/amit/ubsan/jdk/src/hotspot/share/c1/c1_Compiler.cpp:263
    #17 0x3ffaa61ab23 in CompileBroker::invoke_compiler_on_method(CompileTask*) /home/amit/ubsan/jdk/src/hotspot/share/compiler/compileBroker.cpp:2319
    #18 0x3ffaa61c7d5 in CompileBroker::compiler_thread_loop() /home/amit/ubsan/jdk/src/hotspot/share/compiler/compileBroker.cpp:1977
    #19 0x3ffab075099 in JavaThread::thread_main_inner() /home/amit/ubsan/jdk/src/hotspot/share/runtime/javaThread.cpp:758
    #20 0x3ffac4a5ec9 in Thread::call_run() /home/amit/ubsan/jdk/src/hotspot/share/runtime/thread.cpp:232
    #21 0x3ffabd9458f in thread_native_entry /home/amit/ubsan/jdk/src/hotspot/os/linux/os_linux.cpp:858
    #22 0x3ffaf716295 in start_thread nptl/pthread_create.c:442
    #23 0x3ffaf78ff8d  (/lib/s390x-linux-gnu/libc.so.6+0x10ff8d)
Comments
Changeset: 77e49322 Branch: master Author: Amit Kumar <amitkumar@openjdk.org> Date: 2024-12-12 09:51:56 +0000 URL: https://git.openjdk.org/jdk/commit/77e493226d6875bb73faaadedc4170dbb5d4fdc5
12-12-2024
ILW = Potential integer overflow in C1 optimization (might lead to incorrect results), not an issue with current toolchain, no workaround but disable compilation of affected method = MLM = P4
12-12-2024
How did this end up in hotspot/runtime? Moving to compiler.
04-12-2024
> [~mbaesken] I have drafted the change: https://github.com/openjdk/jdk/pull/22144 I guess with that we don't need architecture specific check Okay, let's see what the outcome of the review is.
15-11-2024
[~mbaesken] I have drafted the change: https://github.com/openjdk/jdk/pull/22144 I guess with that we don't need architecture specific checks. Test passes on s390x now. If we agree then I will update the JBS issue accordingly.
15-11-2024
I can add checks for both ppc & s390x with this issue or you want to handle separately ? > should we do the sanity checks also on ppc ? There is no harm in having safety nets :-)
15-11-2024
Hi [~amitkumar] I am not aware of similar failures on other architectures (we currently run ubsan from time to time on Linux ppc64le and Linux x86_64 so I cannot say much more about others). > I see that risc-v & x86 are guarded like this: > if (tmp->is_valid() && c > 0 && c < max_jint) { Hi [~mdoerr] I think this is about the checks done in LIRGenerator::strength_reduce_multiply on some platforms e.g. https://github.com/openjdk/jdk/blob/21966942b6b5341d0d221d10c3eaa629e543d017/src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp#L272 https://github.com/openjdk/jdk/blob/21966942b6b5341d0d221d10c3eaa629e543d017/src/hotspot/cpu/riscv/c1_LIRGenerator_riscv.cpp#L237 should we do the sanity checks also on ppc ? https://github.com/openjdk/jdk/blob/21966942b6b5341d0d221d10c3eaa629e543d017/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp#L297 (at least the "c > 0 && c < max_jint") looks like those were added on e.g. x86_64 as part of 8181872: C1: possible overflow when strength reducing integer multiply by constant https://bugs.openjdk.org/browse/JDK-8181872 https://github.com/openjdk/jdk/commit/2a0ab692f73457453bf0e2f647452f2e337d9857 (but ppc64 was ignored)
15-11-2024
[~mbaesken] did you see similar failure for ppc or other architecture ? When I ran compiler/c1/MultiplyByMaxInt.java, in c1_LIRGenerator.cpp: case Bytecodes::_imul: { bool did_strength_reduce = false; if (right->is_constant()) { jint c = right->as_jint(); if (c > 0 && is_power_of_2(c)) { // do not need tmp here __ shift_left(left_op, exact_log2(c), result_op); did_strength_reduce = true; } else { did_strength_reduce = strength_reduce_multiply(left_op, c, result_op, tmp_op); } } // we couldn't strength reduce so just emit the multiply if (!did_strength_reduce) { __ mul(left_op, right_op, result_op); } } break; jint c = right->as_jint(); here c will result into INT_MAX, which isn't a power of 2 and will go else-block. strength_reduce_multiply() method does 2 checks, is_power_of_2(c+1) & is_power_of_2(c-1) is_power_of_2(c+1) will result into INT_MAX + 1. I see that risc-v & x86 are guarded like this: if (tmp->is_valid() && c > 0 && c < max_jint) { But not s390x, ppc and aarch64.
15-11-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/22144 Date: 2024-11-15 10:04:51 +0000
15-11-2024