After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 728694 - g_get_monotonic_time() makes incorrect assumptions about mach_absolute_time() value
g_get_monotonic_time() makes incorrect assumptions about mach_absolute_time()...
Status: RESOLVED DUPLICATE of bug 728123
Product: glib
Classification: Platform
Component: mainloop
2.40.x
Other Mac OS
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2014-04-22 03:31 UTC by Misty De Meo
Modified: 2014-04-22 13:01 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Misty De Meo 2014-04-22 03:31:08 UTC
The recent changes to g_get_monotonic_time() make some incorrect assumptions about the units returned by mach_absolute_time(), breaking this function on non-Intel Darwin.

mach_absolute_time() returns "absolute_time_units" of nonspecified type. These are documented as being CPU dependent (https://developer.apple.com/library/mac/qa/qa1398/_index.html), so a mach_timebase_info_data_t struct is provided. This struct provides a numerator and denominator which can be used to translate mach_absolute_time() into seconds.

However, g_get_monotonic_time() makes the assumption that the units are actually scaled seconds. A comment in the function says that "We've only ever observed this to be 1/1"; the original bug for this (https://bugzilla.gnome.org/show_bug.cgi?id=724687) notes a specific counterexample given by Apple in their tech note, but disregards it.

Unfortunately, the 1/1 fraction is only actually consistent on Intel: on ARM and PowerPC, different values are used. PowerPC has different values on every computer I've seen, such as 1000000000/33329253, and I've seen a documented fraction on ARM of 125/3 on a couple of different devices (http://iosdeveloperzone.com/2011/05/03/quick-performance-measurements/). It's also possible that this will change on future Intel Macs.

The only way to reliably get the value in a platform-nonspecific way is calculate using both the numer and denom, e.g. something along the lines of

mach_absolute_time () * ((double) timebase_info.numer / (double) timebase_info.denom) / 1000;
Comment 1 Allison Karlitskaya (desrt) 2014-04-22 13:01:12 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 728123 ***