Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
GitHub or Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 70 [details]
sample test case
After 1 to 3 hours this will produce a negative value on Windows XP SP3
I've spent the last couple days tracking what I believe is the source of this bug.
Basically, the time calculations in mono_100ns_ticks overflows on machines where the high-precision counter frequency is really high.
Here we have a lot of Dell Precision 390 machines on which QueryPerformanceFrequency returns 2394170000. Their timers all break within 6 to 12 minutes.
The fault is in mono/utils/mono-time.c:
#define MTICKS_PER_SEC 10000000
static LARGE_INTEGER freq;
if (!freq.QuadPart && !QueryPerformanceFrequency (&freq))
return mono_100ns_datetime ();
return value.QuadPart * MTICKS_PER_SEC / freq.QuadPart;
Here, at the specified frequency, it takes 385 seconds to overflow. On my main machine the frequency is 2337929, so this is 5 to 10 days, but this is just as bad.
This issue is extremely severe since it causes all Timers to be scheduled improperly. This has the potential to break other time sensitive services as well.
I have noticed this issue on Unity 3.2.0f4 (which uses mono 2.6 + fixes) but looking at the latest mono repository nothing seems to have changed in that regard.
Hope that helps!
This should be fixed in git.
I fear you did not quite grasp the nature of the issue.
The problem has to do with the range of frequencies we can expect from the performance counter. The machine that caused me trouble has a counter frequency of 2394170000 Hz. That's the rate at which 'value' grows. Multiplying that by 10 000 000 leaves you with only 6-12 minutes before the multiplication overflows, depending on the initial value. Multiplying the difference with the start_time only makes that more predictable. (cur_time - start_time) will still grow at the same rate. The counter now overflows at _exactly_ 385.24s.
I get a feeling that frequencies that high are not very common (or the bug would have been fixed a while ago) but if you don't want your timers to die after a couple of days, better give this some thoughts before claiming it fixed.
The multiplication was meant to be done with floating point numbers, complete fix in git.