RFR: 8333098: ubsan: bytecodeInfo.cpp:318:59: runtime error: division by zero

[Vladimir Kozlov]

On Fri, 16 Aug 2024 19:33:15 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> When running test
>> compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.java
>> with ubsan enabled binaries we run into the issue reported below.
>> Reason seems to be that we divide by zero in the code in some special cases (we should instead check for `CompilationPolicy::min_invocations() == 0 `and handle it separately).
>> 
>> /jdk/src/hotspot/share/opto/bytecodeInfo.cpp:318:59: runtime error: division by zero
>>     #0 0x7f5145c0dda2 in InlineTree::should_not_inline(ciMethod*, ciMethod*, int, bool&, ciCallProfile&) src/hotspot/share/opto/bytecodeInfo.cpp:318
>>     #1 0x7f51466366d7 in InlineTree::try_to_inline(ciMethod*, ciMethod*, int, JVMState*, ciCallProfile&, bool&) src/hotspot/share/opto/bytecodeInfo.cpp:382
>>     #2 0x7f514663d36b in InlineTree::ok_to_inline(ciMethod*, JVMState*, ciCallProfile&, bool&) src/hotspot/share/opto/bytecodeInfo.cpp:596
>>     #3 0x7f51470dffd6 in Compile::call_generator(ciMethod*, int, bool, JVMState*, bool, float, ciKlass*, bool) src/hotspot/share/opto/doCall.cpp:189
>>     #4 0x7f51470e18ab in Parse::do_call() src/hotspot/share/opto/doCall.cpp:641
>>     #5 0x7f514887dbf1 in Parse::do_one_block() src/hotspot/share/opto/parse1.cpp:1607
>>     #6 0x7f514887fefa in Parse::do_all_blocks() src/hotspot/share/opto/parse1.cpp:724
>>     #7 0x7f514888d4da in Parse::Parse(JVMState*, ciMethod*, float) src/hotspot/share/opto/parse1.cpp:628
>>     #8 0x7f51469d8418 in ParseGenerator::generate(JVMState*) src/hotspot/share/opto/callGenerator.cpp:99
>>     #9 0x7f5146d99cff in Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*) src/hotspot/share/opto/compile.cpp:793
>>     #10 0x7f51469d5ebf in C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*) src/hotspot/share/opto/c2compiler.cpp:142
>>     #11 0x7f5146db0274 in CompileBroker::invoke_compiler_on_method(CompileTask*) src/hotspot/share/compiler/compileBroker.cpp:2303
>>     #12 0x7f5146db2826 in CompileBroker::compiler_thread_loop() src/hotspot/share/compiler/compileBroker.cpp:1961
>>     #13 0x7f51478d475a in JavaThread::thread_main_inner() src/hotspot/share/runtime/javaThread.cpp:759
>>     #14 0x7f51491620ea in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
>>     #15 0x7f51487ac201 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:846
>>     #16 0x7f514e5cf6e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73)
>>     #17 0x7f514db1550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: ...
>
> First, I think `Tier4MinInvocationThreshold` and `Tier3MinInvocationThreshold` should be `double` flags. I see that they are used only in `double` type expressions (usually with scaling value which is `double`). May be another RFE.
> 
> I agree that we need to check `Tier4MinInvocationThreshold` == 0  because it is acceptable value and can be specified on command line. I think 0 means that `(freq < min_freq)` is always `true`. So your change could be changed:
> 
>    if (cp_min_inv == 0) {
>        // Tier4MinInvocationThreshold == 0 means we should not inline
>        min_freq = freq + 1.;

> @vnkozlov , I think this is happening because the scaling factor is 0.001, so 600 turns into 0.

Yes, I noticed that. But my point is that the flag's definition allows 0 regardless scaling factor:

  product(intx, Tier4InvocationThreshold, 5000,                             \
          "Compile if number of method invocations crosses this "           \
          "threshold")                                                      \
          range(0, max_jint)                                                \

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20615#issuecomment-2294343354