bug#64836: pygobject GTK modules lookup fails following CUPS graft

bug#64836: pygobject GTK modules lookup fails following CUPS graft

[Maxim Cournoyer]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

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:


[-- Attachment #2: hang-repro.py --]
[-- Type: application/octet-stream, Size: 513 bytes --]

#!/usr/bin/env python3

import sys

import wx

class DummyApp(wx.App):
    """The application class."""

    def OnInit(self):
        """Main initialization routine."""
        super().OnInit()

        import gi
        gi.require_version('Gtk', '3.0')
        # Hangs here ->
        from gi.repository import Gtk, Gdk, Gio
        sys.exit(0)             # never reached

        return True


def main():
    # Spin up the GUI.
    app = DummyApp()
    app.MainLoop()


if __name__ == "__main__":
    main()

[-- Attachment #3: Type: text/plain, Size: 2173 bytes --]


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

bug#64836: pygobject GTK modules lookup fails following CUPS graft

[Maxim Cournoyer]

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

bug#64836: pygobject GTK modules lookup fails following CUPS graft

[Maxim Cournoyer]

Hi,

Maxim Cournoyer <maxim.cournoyer@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