JDK-8346888 : [ubsan] block.cpp:1617:30: runtime error: 9.97582e+36 is outside the range of representable values of type 'int'
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 21,24,25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2024-12-30
  • Updated: 2025-04-22
  • Resolved: 2025-03-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 21 JDK 24 JDK 25
21.0.8Fixed 24.0.2Fixed 25 b17Fixed
Related Reports
Relates :  
JDK-6510732 - Compute consistent block frequencies
Relates :  
JDK-8296389 - C2: PhaseCFG::convert_NeverBranch_to_Goto must handle both orders of successors
Relates :  
JDK-8353041 - NeverBranchNode causes incorrect block frequency calculation
Description
When running jtreg tests on macOS aarch64 with ubsanized binaries, in the test
java/foreign/TestHandshake
this error/warning is reported :
 
jdk/src/hotspot/share/opto/block.cpp:1617:30: runtime error: 9.97582e+36 is outside the range of representable values of type 'int'
UndefinedBehaviorSanitizer:DEADLYSIGNAL
UndefinedBehaviorSanitizer: nested bug in the same thread, aborting.
 
seems it happens in this calculation (float value does not fit into an int)  :  int to_pct = (int) ((100 * freq) / target->_freq);
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk21u-dev/pull/1583 Date: 2025-04-03 10:51:04 +0000
03-04-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk24u/pull/177 Date: 2025-04-03 10:43:36 +0000
03-04-2025
jdk24u backport request I would like to have the patch in jdk24u as well, because the issue is present there too. The backport is clean and low risk.
03-04-2025
Changeset: ddf326b8 Branch: master Author: Matthias Baesken <mbaesken@openjdk.org> Date: 2025-03-28 08:19:20 +0000 URL: https://git.openjdk.org/jdk/commit/ddf326b8e6e50403303b410635e4c26d7bf56aaa
28-03-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23962 Date: 2025-03-10 13:37:23 +0000
10-03-2025
I came to the same conclusion, that using floats that can become infinity was better than checking for overlow/saturation on ints, which looking into JDK-8306481.
07-03-2025
> I guess we could do that. I'm wondering though, if `from_pct` and `to_pct` should not just be floats as well. looks like these values are in the end compared to BlockLayoutMinDiamondPercentage which is an intx : 765 int from_infrequent() const { return from_pct() < BlockLayoutMinDiamondPercentage; } 766 int to_infrequent() const { return to_pct() < BlockLayoutMinDiamondPercentage; } I am not very familiar with this coding; should we maybe cast BlockLayoutMinDiamondPercentage to float (or make it a float?) and then make `from_pct` and `to_pct' float too?
07-03-2025
> Hi [~chagedorn] should we add a check and set the value to MAXINT in case it overflows ? I guess we could do that. I'm wondering though, if `from_pct` and `to_pct` should not just be floats as well.
07-03-2025
Seems java/text/Format/CompactNumberFormat/SPIProviderTest triggers a similar issue (also on macosaarch64 with ubsan enabled) : src/hotspot/share/opto/block.cpp:1616:30: runtime error: 1.416e+33 is outside the range of representable values of type 'int' STATUS:Passed. #0 0x108f59970 in PhaseBlockLayout::find_edges() block.cpp:1616 #1 0x108f5be44 in PhaseBlockLayout::PhaseBlockLayout(PhaseCFG&) block.cpp:1832 #2 0x108f5c1a0 in PhaseBlockLayout::PhaseBlockLayout(PhaseCFG&) block.cpp:1812 #3 0x10920b3b8 in Compile::Code_Gen() compile.cpp:2988 #4 0x109208250 in Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*) compile.cpp:881 #5 0x10920b4fc in Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*) compile.cpp:683 #6 0x109094e3c in C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*) c2compiler.cpp:141 #7 0x10922e57c in CompileBroker::invoke_compiler_on_method(CompileTask*) compileBroker.cpp:2331 #8 0x10922db64 in CompileBroker::compiler_thread_loop() compileBroker.cpp:1975 #9 0x109840b18 in JavaThread::thread_main_inner() javaThread.cpp:776 #10 0x10a211298 in Thread::call_run() thread.cpp:231 #11 0x109daa890 in thread_native_entry(Thread*) os_bsd.cpp:601 #12 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) #13 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
06-03-2025
Hi [~chagedorn] should we add a check and set the value to MAXINT in case it overflows ?
06-03-2025
Initial ILW = Int variable overflowed, no wrong execution/behavior observed, possibly disable compilation of affected method = MLM = P4
06-01-2025
Similar issue : test jdk/jfr/jvm/TestGetEventWriter.java#default (macOS aarch64) jdk/src/hotspot/share/opto/block.cpp:1617:30: runtime error: 9e+36 is outside the range of representable values of type 'int' UndefinedBehaviorSanitizer:DEADLYSIGNAL UndefinedBehaviorSanitizer: nested bug in the same thread, aborting. compiler/escapeAnalysis/TestInvalidLocation.java (macOS aarch64) jdk/src/hotspot/share/opto/block.cpp:1617:30: runtime error: 3.64498e+36 is outside the range of representable values of type 'int' UndefinedBehaviorSanitizer:DEADLYSIGNAL
02-01-2025