JDK-8331799 : ubsan: g1Policy.cpp:1114:33: runtime error: 2.71198e+167 is outside the range of representable values of type 'const unsigned long'
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 23
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: os_x
  • CPU: x86
  • Submitted: 2024-05-07
  • Updated: 2024-05-16
  • Resolved: 2024-05-16
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.
Other
tbdResolved
Related Reports
Duplicate :  
Relates :  
Description
With ubsan, we run into the following error :

jdk/src/hotspot/share/gc/g1/g1Policy.cpp:1114:33: runtime error: 2.71198e+167 is outside the range of representable values of type 'const unsigned long'
    #0 0x119407cf8 in G1Policy::predict_eden_copy_time_ms(unsigned int, unsigned long*) const g1Policy.cpp:1114
    #1 0x11936469f in G1CollectionSet::finalize_young_part(double, G1SurvivorRegions*) g1CollectionSet.cpp:304
    #2 0x119365890 in G1CollectionSet::finalize_initial_collection_set(double, G1SurvivorRegions*) g1CollectionSet.cpp:436
    #3 0x11943eb51 in G1YoungCollector::calculate_collection_set(G1EvacInfo*, double) g1YoungCollector.cpp:283
    #4 0x11943f02b in G1YoungCollector::pre_evacuate_collection_set(G1EvacInfo*) g1YoungCollector.cpp:497
    #5 0x119440d17 in G1YoungCollector::collect() g1YoungCollector.cpp:1088
    #6 0x11935d758 in G1CollectedHeap::do_collection_pause_at_safepoint_helper() g1CollectedHeap.cpp:2493
    #7 0x11935a5d6 in G1CollectedHeap::do_collection_pause_at_safepoint() g1CollectedHeap.cpp:2409
    #8 0x11943d820 in VM_G1CollectForAllocation::doit() g1VMOperations.cpp:121
    #9 0x119f8475d in VM_Operation::evaluate() vmOperations.cpp:75
    #10 0x119f9f16b in VMThread::evaluate_operation(VM_Operation*) vmThread.cpp:283
    #11 0x119fa0067 in VMThread::inner_execute(VM_Operation*) vmThread.cpp:427
    #12 0x119f9ef8d in VMThread::loop() vmThread.cpp:493
    #13 0x119f9ed15 in VMThread::run() vmThread.cpp:177
    #14 0x119eb10d6 in Thread::call_run() thread.cpp:221
    #15 0x119abece4 in thread_native_entry(Thread*) os_bsd.cpp:598
    #16 0x7fff204338fb in _pthread_start+0xdf (libsystem_pthread.dylib:x86_64+0x68fb)
    #17 0x7fff2042f442 in thread_start+0xe (libsystem_pthread.dylib:x86_64+0x2442)

Seems converting a double to size_t at this point is not always working well.
Comments
Got this today from ubsan ( G1Policy::predict_eden_copy_time_ms) : runtime error: -1.25471e+248 is outside the range of representable values of type 'const unsigned long' Should we maybe add some assertion / guarantee to G1Policy::predict_eden_copy_time_ms or is it just expected that the value sometimes is out of range and does not fit into size_t ? I added a bit of output and got accum_surv_rate_pred result multiplied -125470688123220547976673906919092959576032492039213912949736814067915722612923682302219945910026189495324875033116793226235002646037743647195748146761122099551450957675102169600481586266318865881424761720599214303727024605438524081382220300610961408.000000 (by 16777216) is larger than SIZE_MAX. the accum_surv_rate_pred = _eden_surv_rate_group->accum_surv_rate_pred(count - 1); looks very large to me, is there something wrong with it ?
15-05-2024

> Would we notice that, e.g. get a compile time warning on one of our supported compilers? We enable -Wuninitialized for gcc and friends, but an uninitialized data member might be hard for the compiler to track.
10-05-2024

> I wonder if there is an uninitialized variable involved somewhere in the calculation? Would we notice that, e.g. get a compile time warning on one of our supported compilers?
10-05-2024

I wonder if there is an uninitialized variable involved somewhere in the calculation?
10-05-2024