GNU bug report logs - #64836
pygobject GTK modules lookup fails following CUPS graft

Previous Next

To reply to this bug, email your comments to 64836 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: bug-guix <bug-guix <at> gnu.org>
Subject: pygobject GTK modules lookup fails following CUPS graft
Date: Mon, 24 Jul 2023 13:30:20 -0400

[Message part 1 (text/plain, inline)]

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:

--8<---------------cut here---------------start------------->8---
$ guix time-machine --commit=2986ba899f5ee374008c501e26fb653147ed7891 \
  -- shell --rebuild-cache --pure python python-pygobject python-wxpython gtk+ \
  -- ./hang-repro.py
--8<---------------cut here---------------end--------------->8---

Where hang-repro.py contains:

[hang-repro.py (application/octet-stream, inline)]

[Message part 3 (text/plain, inline)]

The output produced is:

--8<---------------cut here---------------start------------->8---
/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()
--8<---------------cut here---------------end--------------->8---

and execution hangs (!)

The parent commit doesn't exhibit the problem:

--8<---------------cut here---------------start------------->8---
$ guix time-machine --commit=88d107b2b9bf72a628065a1475ecce7b49852c35 \
  -- shell --rebuild-cache --pure python python-pygobject python-wxpython gtk+ \
  -- ./hang-repro.py
$ echo $?
0
--8<---------------cut here---------------end--------------->8---

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

Message #8 received at 64836 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: 64836 <at> debbugs.gnu.org
Cc: Tobias Geerinckx-Rice <me <at> tobias.gr>
Subject: Re: bug#64836: pygobject GTK modules lookup fails following CUPS graft
Date: Tue, 25 Jul 2023 10:18:27 -0400

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

Message #11 received at 64836 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: 64836 <at> debbugs.gnu.org
Cc: Tobias Geerinckx-Rice <me <at> tobias.gr>
Subject: Re: bug#64836: pygobject GTK modules lookup fails following CUPS graft
Date: Tue, 25 Jul 2023 11:35:23 -0400

Hi,

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

> 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:

--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---

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:

--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---

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

A grep such as

--8<---------------cut here---------------start------------->8---
grep --include='*.so' -rn --text wxwidgets-3.2 \
  /gnu/store/v4xz45cwj88p3l6x1nmvxwg0yrcsg7hd-python-wxpython-4.2.0
--8<---------------cut here---------------end--------------->8---

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.