RFR: 8346888: [ubsan] block.cpp:1617:30: runtime error: 9.97582e+36 is outside the range of representable values of type 'int'

Dean Long dlong at openjdk.org
Tue Mar 11 00:04:55 UTC 2025


On Mon, 10 Mar 2025 13:37:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running jtreg tests on macOS aarch64 with ubsan - enabled 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);

src/hotspot/share/opto/block.cpp line 1617:

> 1615:           float f_from_pct = (100 * freq) / b->_freq;
> 1616:           float f_to_pct = (100 * freq) / target->_freq;
> 1617:           int from_pct = (f_from_pct < (float)INT_MAX) ? (int)f_from_pct : INT_MAX;

I think (float)INT_MAX is problematic.  Due to rounding, isn't the result actually greater than INT_MAX?
Does it even make sense to have a "pct" that is greater than 100 here?
Do we want `int from_pct = MIN2((double)INT_MAX, (double)f_from_pct);` or maybe
`int from_pct = MIN2((100.0, (double)f_from_pct);`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23962#discussion_r1988172603


More information about the hotspot-compiler-dev mailing list