pygobject GTK modules lookup fails following CUPS graft

  • Open
  • quality assurance status badge
Details
One participant
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Maxim Cournoyer
Severity
normal
M
M
Maxim Cournoyer wrote on 24 Jul 2023 19:30
(name . bug-guix)(address . bug-guix@gnu.org)
87zg3lfc9f.fsf@gmail.com
Hi,

I'm still quite puzzled by this, but I'm relatively confident that
commit 2986ba899f5ee374008c501e26fb653147ed7891 ("gnu: cups: Replace
with 2.4.6 [fixes CVE-2023-34241].") caused the following wxPython /
pygobject script to fail:

Toggle snippet (5 lines)
$ guix time-machine --commit=2986ba899f5ee374008c501e26fb653147ed7891 \
-- shell --rebuild-cache --pure python python-pygobject python-wxpython gtk+ \
-- ./hang-repro.py

Where hang-repro.py contains:
Attachment: hang-repro.py
The output produced is:

Toggle snippet (16 lines)
/gnu/store/88r0c82k32zq8nmx5abn1fxvf7wxyw0j-profile/lib/python3.10/site-packages/gi/module.py:163: Warning: cannot register existing type 'GtkWidget'
g_type = info.get_g_type()
/gnu/store/88r0c82k32zq8nmx5abn1fxvf7wxyw0j-profile/lib/python3.10/site-packages/gi/module.py:163: Warning: cannot add class private field to invalid type '<invalid>'
g_type = info.get_g_type()
/gnu/store/88r0c82k32zq8nmx5abn1fxvf7wxyw0j-profile/lib/python3.10/site-packages/gi/module.py:163: Warning: cannot add private field to invalid (non-instantiatable) type '<invalid>'
g_type = info.get_g_type()
/gnu/store/88r0c82k32zq8nmx5abn1fxvf7wxyw0j-profile/lib/python3.10/site-packages/gi/module.py:163: Warning: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed
g_type = info.get_g_type()
/gnu/store/88r0c82k32zq8nmx5abn1fxvf7wxyw0j-profile/lib/python3.10/site-packages/gi/module.py:163: Warning: cannot register existing type 'GtkBuildable'
g_type = info.get_g_type()
/gnu/store/88r0c82k32zq8nmx5abn1fxvf7wxyw0j-profile/lib/python3.10/site-packages/gi/module.py:163: Warning: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed
g_type = info.get_g_type()
/gnu/store/88r0c82k32zq8nmx5abn1fxvf7wxyw0j-profile/lib/python3.10/site-packages/gi/module.py:163: Warning: g_once_init_leave: assertion 'result != 0' failed
g_type = info.get_g_type()

and execution hangs (!)

The parent commit doesn't exhibit the problem:

Toggle snippet (7 lines)
$ guix time-machine --commit=88d107b2b9bf72a628065a1475ecce7b49852c35 \
-- shell --rebuild-cache --pure python python-pygobject python-wxpython gtk+ \
-- ./hang-repro.py
$ echo $?
0

I've run the above using Guix at commit 21b718f, but since I'm using
time-machine, it shouldn't matter.

I've very puzzled as to why grafting CUPS could create such a problem
:-). Help wanted!

--
Thanks,
Maxim
M
M
Maxim Cournoyer wrote on 25 Jul 2023 16:18
(address . 64836@debbugs.gnu.org)(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
871qgw2hxo.fsf@gmail.com
Hello,

I initially thought the issue may be with the GTK .typelib files not
getting grafted correctly, but I've verified them and they appear
correct (there's a single file name for the shared library, and it
appears in the .typelib in full, gets grafted correctly).

So I'm now leaning toward a different explanation: wxWidgets or wxPython
retaining a reference to the ungrafted GTK library, loading it first,
then pygobject attempts to load the grafted GTK, and both conflict,
producing error messages such as "Warning: cannot register existing type
'GtkWidget'".

I'll now attempt to verify this potential cause.

--
Thanks,
Maxim
M
M
Maxim Cournoyer wrote on 25 Jul 2023 17:35
(address . 64836@debbugs.gnu.org)(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
87wmyo0zt0.fsf@gmail.com
Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (15 lines)
> Hello,
>
> I initially thought the issue may be with the GTK .typelib files not
> getting grafted correctly, but I've verified them and they appear
> correct (there's a single file name for the shared library, and it
> appears in the .typelib in full, gets grafted correctly).
>
> So I'm now leaning toward a different explanation: wxWidgets or wxPython
> retaining a reference to the ungrafted GTK library, loading it first,
> then pygobject attempts to load the grafted GTK, and both conflict,
> producing error messages such as "Warning: cannot register existing type
> 'GtkWidget'".
>
> I'll now attempt to verify this potential cause.

I think I might have found something fishy; python-wxpython appears to
keep references to unexpected wxwidgets outputs, unless I am
misunderstanding how grafts appear.

Consider, for guix 21b718f:

Toggle snippet (9 lines)
$ guix build wxwidgets
/gnu/store/dkj98zg7d7ijxiyymjxr6l4z2qb71cq4-wxwidgets-3.2.2.1-debug
/gnu/store/40a6chmcvn99dbz1vy16fy88bzfb6bj3-wxwidgets-3.2.2.1

$ guix build --no-grafts wxwidgets
/gnu/store/08mx5x1sblzb39ng9bj5ly2pibxzyx4s-wxwidgets-3.2.2.1-debug
/gnu/store/cm3pyzm7h8h3s4rxdcrfd1qhsby7g911-wxwidgets-3.2.2.1

The grafted version of wxwidgets is
'/gnu/store/cm3pyzm7h8h3s4rxdcrfd1qhsby7g911-wxwidgets-3.2.2.1', which
is the one I'd expect the grafted python-wxpython to refer to, but:

Toggle snippet (8 lines)
$ guix build python-wxpython
/gnu/store/2fbdcwsif1ihb5ig3smcp4g79dh7wxwy-python-wxpython-4.2.0-debug
/gnu/store/v4xz45cwj88p3l6x1nmvxwg0yrcsg7hd-python-wxpython-4.2.0

$ guix gc -R /gnu/store/v4xz45cwj88p3l6x1nmvxwg0yrcsg7hd-python-wxpython-4.2.0 | grep wxwidgets
/gnu/store/nj48sl6wdqh4m4yp8g8r04bx0mxmqfv3-wxwidgets-3.2.2.1

i.e. it refers to a different wxwidgets, which is not the above grafted
nor the ungrafted version (!?).

A grep such as

Toggle snippet (4 lines)
grep --include='*.so' -rn --text wxwidgets-3.2 \
/gnu/store/v4xz45cwj88p3l6x1nmvxwg0yrcsg7hd-python-wxpython-4.2.0

Indeed reveals that the only wxwidgets referred by the shared library
objects is /gnu/store/nj48sl6wdqh4m4yp8g8r04bx0mxmqfv3-wxwidgets-3.2.2.1.

What is going on here? Or is this expected and my understanding of how
grafts work flawed?

--
Thanks,
Maxim
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 64836@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 64836
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch