GNOME Bugzilla – Bug 779184
Gtk+4 (3.89.4) with Quartz backend: all apps segfault
Last modified: 2018-05-02 18:10:51 UTC
Hi, I tried to see how the current unstable gtk+4 release works when compiled on Mac OS X with quartz backend. Though everything compiles fine, all executables I tried segfault immediately. This is the backtrace of gtk4-icon-browser for example: (lldb) run Process 78483 launched: '/Users/awf63395/software/bin/gtk4-icon-browser' (x86_64) 2017-02-24 15:49:47.888746 gtk4-icon-browser[78483:21750657] *** WARNING: Method userSpaceScaleFactor in class NSView is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead. Process 78483 stopped * thread #1: tid = 0x14be381, 0x0000000000000000, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x0000000000000000 error: memory read failed for 0x0 (lldb) bt * thread #1: tid = 0x14be381, 0x0000000000000000, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x0000000000000000 frame #1: 0x00000001005c2e82 libgtk-4.0.dylib`gdk_display_get_monitor(display=0x0000000102802120, monitor_num=0) + 210 at gdkdisplay.c:2338 frame #2: 0x00000001005147f1 libgtk-4.0.dylib`gtk_widget_get_scale_factor(widget=0x000000010284a2e0) + 305 at gtkwidget.c:9425 frame #3: 0x000000010053452c libgtk-4.0.dylib`gtk_window_init(window=0x000000010284a2e0) + 940 at gtkwindow.c:1711 frame #4: 0x0000000100fc658c libgobject-2.0.0.dylib`g_type_create_instance + 621 frame #5: 0x0000000100fb58e4 libgobject-2.0.0.dylib`g_object_new_internal + 52 frame #6: 0x0000000100fb57c4 libgobject-2.0.0.dylib`g_object_new_valist + 1010 frame #7: 0x0000000100fb513b libgobject-2.0.0.dylib`g_object_new + 187 frame #8: 0x00000001000015a8 gtk4-icon-browser`icon_browser_window_new(app=0x00000001028041a0) + 40 at iconbrowserwin.c:874 frame #9: 0x00000001000011dd gtk4-icon-browser`icon_browser_app_activate(app=0x00000001028041a0) + 45 at iconbrowserapp.c:56 frame #10: 0x0000000100faf87d libgobject-2.0.0.dylib`g_closure_invoke + 260 frame #11: 0x0000000100fc3d60 libgobject-2.0.0.dylib`signal_emit_unlocked_R + 2127 frame #12: 0x0000000100fc489d libgobject-2.0.0.dylib`g_signal_emit_valist + 1889 frame #13: 0x0000000100fc4f0a libgobject-2.0.0.dylib`g_signal_emit + 142 frame #14: 0x0000000100e9c2ef libgio-2.0.0.dylib`g_application_real_local_command_line + 1136 frame #15: 0x0000000100131f35 libgtk-4.0.dylib`gtk_application_local_command_line(application=0x00000001028041a0, arguments=0x00007fff5fbff990, exit_status=0x00007fff5fbff98c) + 69 at gtkapplication.c:330 frame #16: 0x0000000100e9af2e libgio-2.0.0.dylib`g_application_run + 305 frame #17: 0x0000000100000eef gtk4-icon-browser`main(argc=1, argv=0x00007fff5fbffa10) + 63 at main.c:7 frame #18: 0x00007fffdb2b0255 libdyld.dylib`start + 1 All other programs I tried crash at the same line in gdkdisplay.c... This was done on a Retina 5K iMac running macOS Sierra. Let me know if more information is required.. Thanks, Tom
The Quartz backend in GTK+ master is completely unmaintained and untested. As of this moment, patches to keep it building and working on modern releases of macOS are very much welcome, otherwise we'll be forced to remove the backend.
It would be most unfortunate if the Quartz backend is dropped, as the X11 backend provides a much inferior user experience on macOS IMHO, especially on Retina screens, which virtually all Macs ship with nowadays. I will have a look at it and see if I can contribute a patch to improve matters.
I had a look this weekend at the code and already made some progress on restoring quartz support. Is there a deadline that I would need to meet before a decision is made regarding the removal of the quartz backend?
Looks like I got things working! Please have a look at my branch at https://github.com/tschoonj/gtk/tree/gtk4-quartz, consisting of two commits: 1) Fixes some configure.ac issues involving the use of 'dnl' with the BSD m4 that ships with macOS 2) Fixes quartz backend for gtk+4
(In reply to Tom Schoonjans from comment #4) > Looks like I got things working! > > Please have a look at my branch at > https://github.com/tschoonj/gtk/tree/gtk4-quartz, consisting of two commits: > > 1) Fixes some configure.ac issues involving the use of 'dnl' with the BSD m4 > that ships with macOS > 2) Fixes quartz backend for gtk+4 Thanks for looking into this! It would be great if you could attach each individual commit to this bug report, so we can do a proper code review. That would speed up inclusion of your work into both the master and the gtk-3-22 stable branches. Thanks again!
*** Bug 777944 has been marked as a duplicate of this bug. ***
Created attachment 347472 [details] [review] Adds quartz backend support to gtk4
Patch has been added. I doubt it will apply cleanly in gtk-3.22 though. At some point I will also try and remove a lot of the deprecated macOS API. Since glib essentially enforces a minimum macOS version of 10.9, it seems to me that all API that has been marked as deprecated before or in 10.9, should be substituted with the Apple recommended alternative API.
(In reply to Tom Schoonjans from comment #8) > Patch has been added. I doubt it will apply cleanly in gtk-3.22 though. We can probably work around that, no worries. > At some point I will also try and remove a lot of the deprecated macOS API. > Since glib essentially enforces a minimum macOS version of 10.9, it seems to > me that all API that has been marked as deprecated before or in 10.9, should > be substituted with the Apple recommended alternative API. Yes, that would be a good goal.
I target OSX 10.7 and I have no trouble compiling glib. Let's be careful we don't unnecessarily remove support for older OSes that are still in use.
(In reply to draymond from comment #10) > I target OSX 10.7 and I have no trouble compiling glib. You are probably compiling an older version of GLib or a patched one. GLib's GNotification API implementation for macOS requires macOS 10.9. > Let's be careful we don't unnecessarily remove support for older OSes that are still in use. macOS 10.7 has received its last security update in 2014; you're targeting an insecure operating system release that was officially put into end-of-life state 3 years ago and has seen 5 updates since its official release date, 2 of which (10.8 and 10.9) are *also* without security patches as of 2016. I think we've been careful enough. Of course, given that you can bundle GLib/GTK+ with your application when targeting macOS, you can choose whatever version you like for older versions of macOS.
I agree completely with Emmanuele on this. There's no reason really why Gtk+4 should support these old macOS versions. That being said, I have no doubt that the good people from Homebrew (of which I am a maintainer) and MacPorts will patch their builds to ensure it runs on the old macOS versions, just like they did with glib.
I've pushed a backport of the monitor support to gtk 3.22 to the osx-monitor branch. Review appreciated. It builds and works fine on this borrowed OSX 10.12 machine.
The branch looks nice. + monitor->refresh_rate = 0; // unknown + monitor->manufacturer = NULL; // unknown + monitor->model = NULL; // unknown + monitor->subpixel_layout = GDK_SUBPIXEL_LAYOUT_UNKNOWN; // unknown The missing bits about the monitor metadata are available via the Display Services API: https://developer.apple.com/reference/coregraphics/quartz_display_services?language=objc You need to iterate over every display mode and fill out the GdkMonitor structures, instead of using NSScreen. e.g. monitor->refresh_rate = CGDisplayModeGetRefreshRate(mode) etc. But as a first approximation, I think it's okay as is. +/* Protocol to build cleanly for OSX < 10.7 */ +@protocol ScaleFactor +- (CGFloat) backingScaleFactor; +@end If we have a cut-off at macOS 10.9, we could just get rid of this; at least, for master.
Would it be possible to get this patch merged in before 3.90.0 is released? Thanks!
The new glib release has removed the hard dependency on macOS 10.9, and should compile fine on older versions of macOS without patching. As I said before, I will at some point try and remove as much as the deprecated API. Is there some consensus as to what is it the oldest macOS release Gtk+4 should support?
(In reply to Tom Schoonjans from comment #16) > The new glib release has removed the hard dependency on macOS 10.9, and > should compile fine on older versions of macOS without patching. What is the oldest macOS version on which this new glib now compiles without problems? > As I said before, I will at some point try and remove as much as the > deprecated API. Is there some consensus as to what is it the oldest macOS > release Gtk+4 should support? I would absolutely not consider anything older than 10.6. But given that 10.6 is also aging, you might want to consider 10.8 as oldest version to support. Given that 10.6 was the last macOS to support 32-bit Intel processors, you might get some people that start shouting. But then again it is my understanding that main Linux distributions are also starting to drop support for 32-bit Intel processors.
(In reply to Kristian Rietveld from comment #17) > What is the oldest macOS version on which this new glib now compiles without > problems? > For what value of problems? I'm applying 6 other patches, though one of them is for PPC, to build on 10.5. IIRC none of them fix build-stoppers, rather they work around behavioral issues. I agree that it's time to cut the cord on older OSX versions. I've announced on gtk-osx-users a 5 year policy: I'll keep things working on up to 5 year old MacOS, which means 10.8 is the oldest until June 2018 (its 5 year release anniversary). Xcodes 7 and 8 will, from the command line, happily support 10.6 and later, just pass -macosx-version-min=10.6.
(In reply to Tom Schoonjans from comment #15) > Would it be possible to get this patch merged in before 3.90.0 is released? > > Thanks! I'll keep it in mind. I won't do the 3.90 release before I get back home and have a chance to do a bit more work on os x. Is the current content of the branch good to go, from your perspective (Emmanuele's comments about future improvements nonwithstanding).
Yep, everything worked fine last time I checked. There are currently no conflicts with master
-- 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/gtk/issues/769.