So here’s a very simple reproducer:
https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/examples/hello-world.c
<https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/examples/hello-world.c>
I’m sure you know, but you build it on 10.7, for example, like this:
clang -g -O0 -o test `pkg-config --cflags --libs gtk+-3.0` hello-world.c
then you can run it, or load it into lldb (even on 10.7, works OK) and start
debugging it.
If you want to also add debugging to gtk3, you would rebuild gtk3 with some
modifications to the portfile to make debugging better, and “keep” the source
code for tracing. Something like this in the gtk3 portfile would do it:
======
$ diff -u gnome/gtk3/Portfile `port file gtk3`
--- gnome/gtk3/Portfile 2022-09-10 15:42:40.000000000 -0700
+++
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/gnome/gtk3/Portfile
2023-01-16 21:36:02.000000000 -0800
@@ -63,6 +63,10 @@
use_autoreconf yes
autoreconf.args -fvi
+
+configure.optflags-delete -Os -O0 -O1 -O2 -O3
+configure.optflags-append -g -O0
+
# gtk3 +quartz uses instancetype which is not available
# before approximately Xcode 4.6 (#49391)
# if building +x11 blacklist comilers that do not support C11
@@ -111,6 +115,8 @@
--disable-schemas-compile \
gio_can_sniff=yes
+configure.args-append --enable-debug=yes
+
build.args-append V=1 \
CPP_FOR_BUILD="${configure.cpp}"
============
and then to rebuild gtk3 with all the debugging and source left behind, you
would do this, perhaps:
sudo port -f uninstall gtk3
(select the quartz variant to uninstall)
sudo port -v -s -k install gtk3 +quartz
and you’d then have a heavily debug-enabled gtk3 with all the source left
behind, so you could step through the code with lldb and view the frame
variables and hopefully steer you in the right direction.
My guess is the error is occurring somewhere in the pango/cairo/harfbuzz trio ,
so you might want to rebuild all those ports with full debugging enabled and
with the source code left behind too, so you can trace those through as well.
Of course, upstream would be helpful. However, to ask them for help, we’d have
to first upgrade/update our gtk3 port and make sure the error still happens
(likely will). Also, have to survey all the patches macports adds to
gtk3/glib2/pango/cairo/harfbuzz and make sure they are all defendable to
upstream.
It’s not easy. I did some of this tonight, and I stepped through the code to
see where the out of memory errors were originating, at least. They are
originating, it seems to me, in the widget redraw code of gtk3, in the part
that pertains to cairo I thought. But that is as far as I got.
As mentioned, the x11 version works nicely still, so the error is somewhere in
the quartz backend, NS* code, etc, and to be honest, that stuff is hard to
debug. The gtk3 interactive debugger unfortunately won’t open when gtk3 is
built with the quartz backend (on 10.7 at least), so that is unfortunate.
Ken
> On Jan 12, 2023, at 5:12 AM, Ken Cunningham <[email protected]>
> wrote:
>
> My guess would be to look at harfbuzz…make sure our patches there still make
> sense, run the test suite. It can be touchy, different compilers can change
> test results, etc.
>
> To disable one port in an overlay with minimal fuss, rename to Portfile to
> something else (I use Portfile.disabled), and portindex ignores it.
>
> K
>
>> On Jan 12, 2023, at 01:42, Riccardo Mottola <[email protected]>
>> wrote:
>>
>> Hi!
>>
>> I did further tests here.
>> In my local repository I pinned also a previous version of pango and
>> pang-devel, but had difficulties "upgarding" to a previous version, how can
>> it be done cleanly?
>>
>> Then I thought of just activating some previous versions… I had a bit mess
>> here and there when rev-upgrade , so I also set back librsvg.
>>
>> The following ports are currently installed:
>> pango @1.42.4_3+quartz+x11 (active)
>> pango @1.50.7_0+quartz+x11
>>
>> The following ports are currently installed:
>> harfbuzz @2.8.2_0
>> harfbuzz @3.4.0_0 (active)
>> harfbuzz @5.2.0_0
>> harfbuzz @5.3.1_0
>>
>> The following ports are currently installed:
>> librsvg @2.40.20_4+quartz (active)
>> librsvg @2.54.5_0
>>
>>
>> I don't remember if I had to touch other stuff… how can I now? Is port
>> installed enough?
>>
>> port list outdated
>> Warning: The 'list' action only shows the currently available version of
>> each port. To see installed versions, use the 'installed' action.
>> emacs-app @28.2 editors/emacs
>> librsvg @2.54.5 graphics/librsvg
>> pango @1.50.3 x11/pango
>> pango @1.50.7 x11/pango
>>
>>
>> emacs-app cannot be upgraded. harfbuzz here is not shown… So I don't think
>> it is perfect.
>>
>> Anyway… I would think that the issue is between pango, harfbuzz and librsvg!
>> Since then recompiling current gimp… has a perfectly working gimp! yay!
>>
>> Riccardo
>>
>> PS: suppose if I have pango and harfbuzz in my local port tree. I want to
>> test with current harfbuzz. How can I "hide" it, but keeping the rest of the
>> local port? Rename the directory? put a command in the portfile… or move the
>> port directory away to be in case put in back.
>>
>>
>>
>> --
>> Sent with GNUMail running on MacOS 10.7
>>
