Fascinating!  Thanks for the report.

Can you please tell me what your exact system configuration is?  What model of Mac and what OS version, particularly...

Cheers

I is a good old (and still fit) "PowerBook G4" running "Leopard":

$ uname -mpv
Darwin Kernel Version 9.8.0: Wed Jul 15 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power Macintosh powerpc

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.5.8
BuildVersion:	9L31a

$ system_profiler | grep "Processor Name"
      Processor Name: PowerPC G4  (3.3)

$ machine
ppc7450

Maybe it is worth noting that ppc operates in big endian mode.

This OS version has been unsupported for 2 years...

(In reply to comment #3)
> This OS version has been unsupported for 2 years...
Does this mean you will ignore the bug? At Macports they have directed me to you as gnome developer. Besides I need to say that the problem was not present until about half a year ago (the last time I was using inkscape). Some glib2 updates in between seem to have brought the "weird mach timebase info" error. What do you think?

(In reply to comment #3)
> This OS version has been unsupported for 2 years...

but it's probably the latest one that exists for ppc?

(In reply to comment #5)
> but it's probably the latest one that exists for ppc?

Yes.  It is.

I didn't consider this facet of our 'new approach to portability'.  I wonder how many people are still using insecure/unpatched version of Mac OS on PPC boxes...

(In reply to comment #6)
> ...
> 
> I didn't consider this facet of our 'new approach to portability'.  I wonder
> how many people are still using insecure/unpatched version of Mac OS on PPC
> boxes...

There is a very helpful contribution on this "Got weird mach timebase info" issue on the macports portal: https://trac.macports.org/ticket/43346#comment:2

The poster has localized the problem inside the function g_get_monotonic_time() in glib/gmain.c and proposes a long double computation for the mach tick period on PPC CPUs (instead of a 64bit integer division). Please see his/her macports patch proposal: https://trac.macports.org/attachment/ticket/43346/patch-glib-gmain-c.diff

I think some PPC related work-around for this issue should be added to glib2! Thanks for your effort!

*** Bug 728694 has been marked as a duplicate of this bug. ***

I think there's probably not much harm in adding a separate path to support this case, but I'd rather not go through the process of converting an int to floating point to perform a multiplication and then back again on systems where we don't need it (ie: the 99% case).

Is there some symbol that is #define'd only on PPC Mac OS that I can #ifdef for in order to do a separate path?


However: note that this will probably only be a temporary fix.  There are some APIs in newer versions of Mac OS that we are looking forward to relying on and we do plan to use them once the older versions fall out of support... at that point, it won't be a simple matter of doing some math in order to get things working again...

There comes a point where we have to stop caring about old versions and that typically coincides with when the OS vendor does the same.  Apple abandoned 10.5 (and PPC) long ago...  It's always possible that you can use older versions of GLib, of course, just as you continue to use older versions of Mac OS...

Created attachment 274897 [details] [review]
Fix g_get_monotonic_time() where the fraction is not 1/1

Since, as I mentioned in #728694, this is also an issue on other non-Intel platforms (read: iOS), I'd rather not special-case PowerPC or make additional assumptions. Instead, why not special-case if the fraction is 1/1, then also provide an alternate codepath that doesn't assume anything about the platform on which it's being run?

I've attached a sample patch that does this.

Created attachment 275596 [details] [review]
Updated g_get_monotonic_time for non-Intel Darwin

I realized there was a minor typo in the previous patch; I've updated it. I've tested it on PowerPC and Intel Macs with success. The following simple test program returns consistent results across Linux, PPC/Darwin and Intel/Darwin:

#include <stdio.h>
#include <unistd.h>
 
#include <glib.h>
 
int main()
{
    gint64 then = g_get_monotonic_time();
    sleep(1);
    gint64 now = g_get_monotonic_time();
    printf("%lli\n", now - then);
}

(In reply to comment #11)
> I realized there was a minor typo in the previous patch; I've updated it. I've
> tested it on PowerPC and Intel Macs with success. ...
Thanks! It would be great if the maintainer could test this patch for g_get_monotonic_time().

Have applied the patch for gmain.c proposed under https://bug728123.bugzilla-attachments.gnome.org/attachment.cgi?id=275596 on foot on my MacOSX 10.5.8 PPC.

Have checked my subsequent glib2 build using the code (saved as g_get_monotonic_time.c and compiled calling gcc g_get_monotonic_time.c -Wall -o g_get_monotonic_time `pkg-config --cflags --
libs glib-2.0`) provided under https://bugzilla.gnome.org/show_bug.cgi?id=728123#c11 - works well:

$ ./g_get_monotonic_time
1000071

This is the time in microsecond between two calls of g_get_monotonic_time() with one second pause. Depending on processor load, this time may vary:

$ ./g_get_monotonic_time
1001127

To me it appears as if the patch can be officially adopted.

BTW, now I again can use inkscape, which was that application I previously could not launch...

Just wanted to check in on the status of this - sorry to bump.

This patch has now been applied locally by both the Tigerbrew (PPC arm of Homebrew) and Macports package managers for about 6 weeks, and it's been tested by a number of users without issue at this point, on both PPC and Intel.

I've been thinking about this issue.

If most people are using GLib on PPC via these package managers (which is almost certainly the case) and if these package managers already carry the patch, then I'm happy to leave well enough alone.

I don't want to add this codepath unless we'll have a mechanism for regularly testing it, and we don't have that.

I hope everyone is OK with that solution...

Thank you, Misty, for writing this patch to help those still on PPC, and I'm happy that it will be useful for that audience.

I understand you don't actively support PPC anymore, but this also fixes other non-Intel platforms. e.g., glib currently won't work on iOS/ARM, due to the same issue that blocks PPC.

I didn't appreciate that before.

http://iosdeveloperzone.com/2011/05/03/quick-performance-measurements/ indeed appears to claim that 125/3 was observed on an iPhone.

Yes, I believe it's CPU-dependent on ARM (if not device-dependent as it is on PPC); it would not surprise me if other values occur as well.

If I find some time I will check on my son's raspberry pi if this popular ARM-based machine is also affected by the "Got weird mach timebase info" error. It should, I think.

This issue is specific to the Darwin timebase function, so unless your son's raspberry pi runs Darwin I doubt it will be affected. Thanks though!

Created attachment 293003 [details] [review]
clean up mach time handling

The current code in gmain.c looks rather odd. Maybe you could consider something along the lines of the attachment. I'd prefer integer arithmetics in this case.

Created attachment 293030 [details] [review]
clean up mach time handling

Update the patch with soothing comments and remove typoed extra call to mach_absolute_time

I tested the above patch on darwin9/ppc and darwin10/x86. Also tested x86 by adding a bogus 10000000:10000001 timebase to exercise the muldiv codepath. Someone might prefer to special case numerator==1 and just do the division then.

Review of attachment 293030 [details] [review]:

I've tested this on a PowerMini running Leopard and it works fine there. I recommend committing it.

I tested the "clean up mach time handling" diff on Tiger/PowerPC running on a PowerMac G4. I was previously hitting this bug when building gstreamer0.10

g-ir-scanner: link: ../libtool --mode=link --tag=CC gcc -std=gnu99 -o /private/tmp/multimedia/gstreamer0.10/work/gstreamer-0.10.36/gst/tmp-introspecteg9Qrj/Gst-0.10 -export-dynamic -isystem /usr/include -I/usr/pkg/include -I/usr/include -pipe -O2 -I/usr/pkg/include -I/usr/include -L/usr/pkg/lib -L/usr/lib /private/tmp/multimedia/gstreamer0.10/work/gstreamer-0.10.36/gst/tmp-introspecteg9Qrj/Gst-0.10.o -L. libgstreamer-0.10.la -L/usr/pkg/lib -lgio-2.0 -lgmodule-2.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl -lxml2
libtool: link: gcc -std=gnu99 -o /private/tmp/multimedia/gstreamer0.10/work/gstreamer-0.10.36/gst/tmp-introspecteg9Qrj/.libs/Gst-0.10 -isystem /usr/include -I/tmp/multimedia/gstreamer0.10/work/.buildlink/include -pipe -O2 /private/tmp/multimedia/gstreamer0.10/work/gstreamer-0.10.36/gst/tmp-introspecteg9Qrj/Gst-0.10.o  -L/tmp/multimedia/gstreamer0.10/work/.buildlink/lib -L. /tmp/multimedia/gstreamer0.10/work/gstreamer-0.10.36/gst/.libs/libgstreamer-0.10.dylib -ldl /tmp/multimedia/gstreamer0.10/work/.buildlink/lib/libgio-2.0.dylib -lresolv /tmp/multimedia/gstreamer0.10/work/.buildlink/lib/libgobject-2.0.dylib /tmp/multimedia/gstreamer0.10/work/.buildlink/lib/libffi.dylib /tmp/multimedia/gstreamer0.10/work/.buildlink/lib/libgmodule-2.0.dylib /tmp/multimedia/gstreamer0.10/work/.buildlink/lib/libgthread-2.0.dylib /tmp/multimedia/gstreamer0.10/work/.buildlink/lib/libglib-2.0.dylib /tmp/multimedia/gstreamer0.10/work/.buildlink/lib/libpcre.dylib /tmp/multimedia/gstreamer0.10/work/.buildlink/lib/libintl.dylib -lc /tmp/multimedia/gstreamer0.10/work/.buildlink/lib/libxml2.dylib /tmp/multimedia/gstreamer0.10/work/.buildlink/lib/libz.dylib /tmp/multimedia/gstreamer0.10/work/.buildlink/lib/liblzma.dylib -lpthread /usr/lib/libiconv.dylib -lm

(<unknown>:28162): GLib-ERROR **: Got weird mach timebase info of 1000000000/41655802.  Please file a bug against GLib.
Command '['/private/tmp/multimedia/gstreamer0.10/work/gstreamer-0.10.36/gst/tmp-introspecteg9Qrj/Gst-0.10', '--introspect-dump=/private/tmp/multimedia/gstreamer0.10/work/gstreamer-0.10.36/gst/tmp-introspecteg9Qrj/functions.txt,/private/tmp/multimedia/gstreamer0.10/work/gstreamer-0.10.36/gst/tmp-introspecteg9Qrj/dump.xml']' returned non-zero exit status -5
Makefile:1784: recipe for target 'Gst-0.10.gir' failed


This patch resolved the issue.

I tested attachment 293030 [details] [review] too on MacOS X 10.5 running on PowerMac G5. After applying the patch the problem completely went away. I hope it will be merged.

Can this fix be committed, please?

ping?

We've been using this patch in MacPorts since May 2014:

https://github.com/macports/macports-ports/commit/91a3a2eb91b3ea62813471bdb280fe2a56491698

It would be great if it could be committed so that non-MacPorts users could benefit from it too.

Tigerbrew has also been using this patch since 2014. It would be great to get this in an official Glib release.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/858.

Remember how I mentioned this breaks iOS? :)

On the new ARM Macs, the timebase unit is also not 1/1 - just like on PowerPC Mac OS and ARM iOS. This time code will not work on ARM Macs. The patch I proposed in 2014 is still valid and should fix the issue by making use of the documented timebase struct to access the value, which is the way that Apple recommend susing this value.

It appears this code hasn't changed much in the past two years, so this bug still exists: https://github.com/GNOME/glib/blob/18b89c1486176568e0d0e04319a4b1bbfc0988fb/glib/gmain.c#L2898

Sorry, totally blanked on the migration. Posted on gitlab.