MySQL Bugs: #108931: The overflow of "unsigned long long int " causes wrong value of TIMER

Bug #108931	The overflow of "unsigned long long int " causes wrong value of TIMER_START.
Submitted:	31 Oct 2022 7:30	Modified:	1 Dec 2022 12:23
Reporter:	yufeng shen	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Performance Schema	Severity:	S2 (Serious)
Version:	5.7	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
We got the same bug issue as the user described in the thread https://bugs.mysql.com/bug.php?id=96774, after doing some investigation,we find this issue caused by a overflow of field TIMER_START with type "unsigned long long int " of the table :performance_schema.events_statements_current; As we know the max value for "unsigned long long int " is 18446744073709551615, that is to say if the result of "(start - m_v0) * m_factor;" larger than 18446744073709551615 (when the uptime over 213.5days ,this would trigger overflow of  (start - m_v0) * m_factor , then the  pico_start in the following code would get a wrong value.

https://github.com/mysql/mysql-server/blob/5.7/storage/perfschema/pfs_timer.cc#L335

void time_normalizer::to_pico(ulonglong start, ulonglong end,
                              ulonglong *pico_start, ulonglong *pico_end, ulonglong *pico_wait)
{
  if (start == 0)
  {
    *pico_start= 0;
    *pico_end= 0;
    *pico_wait= 0;
  }
  else
  {
    *pico_start= (start - m_v0) * m_factor; ////overflow happens here 
    if (end == 0)
    {
      *pico_end= 0;
      *pico_wait= 0;
    }
    else
    {
      *pico_end= (end - m_v0) * m_factor;  ////overflow happens here 
      *pico_wait= (end - start) * m_factor;  ////overflow happens here 
    }
  }
}

How to repeat:
It is hard to repeat the issue as this issue happens when the uptime over 213.5days, however just from theoretical analysis, we can clearly see this bug.

Hi Mr. ddd,

Thank you for your bug report.

However, we see this report as only a Documentation issue. Simply 64-bit integers are largest integers available, so there is no effective solution to this bug. Fixed point arithmetics is not any better at this number of significant digits and floating point can not be used, since it can work with 19 significant digits only.

Also, this report affects both 5.7 and 8.0.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".