We run pluginval on some build nodes and on one build node, that had not been restarted for almost a month, we started to see this:
../thirdparty/juce/modules/juce_opengl/native/juce_OpenGL_osx.h:183:36: runtime error: 4.90689e+09 is outside the range of representable values of type 'int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../thirdparty/juce/modules/juce_opengl/native/juce_OpenGL_osx.h:183:36 in
pluginval received Abort trap: 6, exiting immediately
The code looks like this:
void swapBuffers()
{
auto now = Time::getMillisecondCounterHiRes();
[renderContext flushBuffer];
if (minSwapTimeMs > 0)
{
// When our window is entirely occluded by other windows, flushBuffer
// fails to wait for the swap interval, so the render loop spins at full
// speed, burning CPU. This hack detects when things are going too fast
// and sleeps if necessary.
auto swapTime = Time::getMillisecondCounterHiRes() - now;
auto frameTime = (int) (now - lastSwapTime); <-------- row 183
if (swapTime < 0.5 && frameTime < minSwapTimeMs - 3)
{
if (underrunCounter > 3)
{
Thread::sleep (2 * (minSwapTimeMs - frameTime));
now = Time::getMillisecondCounterHiRes();
}
else
{
++underrunCounter;
}
}
else
{
if (underrunCounter > 0)
--underrunCounter;
}
}
lastSwapTime = now;
}
From the documentation of Time::getMillisecondCounterHiRes()
:
Returns the number of millisecs since a fixed event (usually system startup).
If now
is some value larger than the max value of int
and lastSwapTime
is 0
, then the above UBSAN warning would be printed. If getMillisecondCounterHiRes
returns the number of milliseconds since system startup, then this would happen after ~25 days.
It looks like restarting the machine on our side made the warning go away.
What do you think about casting to std::int64_t
instead, like this:
auto frameTime = (std::int64_t) (now - lastSwapTime);