cx_freeze PyGObject application on Linux

Question

I have a simple PyGObject application:

from gi.repository import Gtk


class Window(Gtk.Window):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.set_border_width(5)

        self.button = Gtk.Button('Test')

        self.box = Gtk.Box()
        self.box.pack_start(self.button, True, True, 0)

        self.add(self.box)
        self.connect('delete-event', Gtk.main_quit)
        self.show_all()


win = Window()
Gtk.main()

I am trying to freeze it using cx_freeze on Linux using following setup.py script:

from cx_Freeze import setup, Executable

setup(name="GUI Test",
      description="GUITest",
      version="0.1",
      options={"build_exe": {"build_exe": "Bin/pygobject",
                             "create_shared_zip": False,
                             }},
      executables=[Executable(script="hello_pygobject.py",
                              targetName="hello",
                              appendScriptToExe=True,
                              )]
      )

And I am running it like this: python3 setup_pygobject.py build

When I try to run the frozen application, I get the following error message:

(process:22538): Gtk-CRITICAL **: gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
Segmentation fault (core dumped)

I am probably missing a bunch of libraries in the directory, such as they have explained for Windows. I have tried pmap to find missing libraries. As a last resort I have also tried to copy all libraries in /usr/lib64/ (+some others I do not remember) to the working directory.

Is there a good way how to find which libraries I need or some better way to fix it?

Related question, but for Windows: Python3 + PyGobject + GTK3 and cx_freeze missing DLLs

EDIT:

I tried to use dbg to investigate core dump. I got this:

...
Core was generated by `./hello'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fd3d009d4ef in _gtk_settings_get_style_cascade () from /lib64/libgtk-3.so.0

When I installed separate debuginfos I got this:

...
Core was generated by `./hello'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  _gtk_settings_get_style_cascade (settings=0x0, scale=scale@entry=1) at gtksettings.c:1764
1764      GtkSettingsPrivate *priv = settings->priv;

When running the application through gdb I got this:

...
(process:21699): Gtk-CRITICAL **: gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed

Program received signal SIGSEGV, Segmentation fault.
_gtk_settings_get_style_cascade (settings=0x0, scale=scale@entry=1) at gtksettings.c:1764
1764      GtkSettingsPrivate *priv = settings->priv;

Stack trace:

(gdb) backtrace
#0  0x00007fffed62c4ef in _gtk_settings_get_style_cascade (settings=0x0, scale=scale@entry=1) at gtksettings.c:1764
#1  0x00007fffed6422d0 in gtk_style_context_init (style_context=0x904080 [GtkStyleContext]) at gtkstylecontext.c:425
#2  0x00007fffef86556b in g_type_create_instance (type=9442240) at gtype.c:1870
#3  0x00007fffef8480ab in g_object_new_internal (class=class@entry=0x901490, params=params@entry=0x0, n_params=n_params@entry=0) at gobject.c:1774
#4  0x00007fffef849991 in g_object_newv (object_type=object_type@entry=9442240, n_parameters=n_parameters@entry=0, parameters=parameters@entry=0x0) at gobject.c:1921
#5  0x00007fffef84a2c4 in g_object_new (object_type=9442240, first_property_name=first_property_name@entry=0x0) at gobject.c:1614
#6  0x00007fffed63f709 in gtk_style_context_new () at gtkstylecontext.c:994
#7  0x00007fffed46086f in _gtk_style_new_for_path (screen=0x0, path=path@entry=0x83dd70) at deprecated/gtkstyle.c:853
#8  0x00007fffed4608ee in gtk_style_new () at deprecated/gtkstyle.c:887
#9  0x00007fffed463569 in gtk_widget_get_default_style () at deprecated/gtkstyle.c:4057
#10 0x00007fffed6dfde5 in gtk_widget_init (widget=<optimized out>) at gtkwidget.c:4510
#11 0x00007fffef865527 in g_type_create_instance (type=9319840) at gtype.c:1864
#12 0x00007fffef8480ab in g_object_new_internal (class=class@entry=0x900b90, params=params@entry=0x0, n_params=n_params@entry=0) at gobject.c:1774
#13 0x00007fffef849991 in g_object_newv (object_type=9319840, n_parameters=0, parameters=0x0) at gobject.c:1921
#14 0x00007fffefece19c in pygobject_constructv () at /home/skontar/Python/Examples/GUI/Bin/pygobject/gi._gi.so
#15 0x00007fffefed57c1 in pygobject_init () at /home/skontar/Python/Examples/GUI/Bin/pygobject/gi._gi.so
#16 0x00007ffff79fec4c in wrap_init () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#17 0x00007ffff79adf31 in PyObject_Call () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#18 0x00007ffff7a60a9f in PyEval_EvalFrameEx () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#19 0x00007ffff7a65de6 in PyEval_EvalCodeEx () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#20 0x00007ffff79d65f8 in function_call () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#21 0x00007ffff79adf31 in PyObject_Call () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#22 0x00007ffff79c3344 in method_call () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#23 0x00007ffff79adf31 in PyObject_Call () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#24 0x00007ffff7a057e0 in slot_tp_init () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#25 0x00007ffff7a03276 in type_call () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#26 0x00007ffff79adf31 in PyObject_Call () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#27 0x00007ffff7a5de0a in PyEval_EvalFrameEx () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#28 0x00007ffff7a65de6 in PyEval_EvalCodeEx () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#29 0x00007ffff7a65e8b in PyEval_EvalCode () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#30 0x00007ffff7a5936a in builtin_exec () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#31 0x00007ffff7a64f1f in PyEval_EvalFrameEx () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#32 0x00007ffff7a65de6 in PyEval_EvalCodeEx () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#33 0x00007ffff7a65e8b in PyEval_EvalCode () at /home/skontar/Python/Examples/GUI/Bin/pygobject/libpython3.4m.so.1.0
#34 0x000000000040192c in  ()
#35 0x00007ffff738f700 in __libc_start_main (main=0x4011e0, argc=1, argv=0x7fffffffe598, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe588)
    at libc-start.c:289
#36 0x0000000000401c69 in  ()

EDIT 2:

Relevant packages:

python3.x86_64            3.4.2-6.fc22
python3-gobject.x86_64    3.16.2-1.fc22   

cx-Freeze (4.3.4)

Dangelo

You can try running it through gdb to get more details on the nature of the segmentation fault (or inspect the core dump with gdb). – Acidfast

@Acidfast I tried (never did that before). But I do not find the output any useful. – Dangelo

True, though at least you now know that the segfault is caused by a null pointer in the gtk3 library (settings == NULL so settings->priv segfaults). I'm not familiar with cx_Freeze myself unfortunately. This may be a tough one to crack. – Acidfast

what's the stack trace when it seg faults? Maybe you can figure out where that settings pointer is coming from, and find a work around to assign it with something. – Plumbiferous

@Plumbiferous I am not really looking into fixing PyGObject. It works when ran from Python, but does not work when cx_freezed. I was able to do the same for Tkinter, wxPython, and PyQt, in all cases it was some missing library. So I assume that it is similar case, but in this case I am not able to understand what is missing. Also the Windows explanation on the wiki page leads me to this conclusion. Anyway, I am including the trace. – Dangelo

It's not uncommon (so I've found) for packages to be missing something such as a library that expect to be called in a certain way, and so loads child libraries assuming it was, only for something else to load it, in a different way that breaks that assumption. Clearly you've found a bug, your options are to fix it, work around it, or live with it. – Plumbiferous

I tried to find the dev packages containing the sources in your stack, so I could see if I could find it, but I can't. If I could, I'd look at g_type_create_instance calling gtk_style_context_init and see why settings isn't defined. Maybe g_object_new_internal should be passing in some params. If you can identify the bug in PyGObject, then you may be able to work around it, without recompiling. That's what I would do anyway. – Plumbiferous

If you want to tell me which packages (including versions) you have installed, if I have time, I'll install them and see if I can see the problem – Plumbiferous

@Plumbiferous Added packages. I believe these are the only ones needed. Cx_freeze is installed through pip. – Dangelo

@Plumbiferous The result is kind of expected BTW, because pyGObject does dynamic introspection and imports so cx_freeze cannot detect dependent libraries at all. So basically first call from gi._gi.so is expected to fail. I just did not expect to not be able to fix it by copying a few files to the bin directory. – Dangelo

Answer 1

So the problem was not in missing libraries (as they were in the path anyway) but missing package in setup.py script. The correct setup is as follows:

from cx_Freeze import setup, Executable

setup(name="GUI Test",
      description="GUITest",
      version="0.1",
      options={"build_exe": {"build_exe": "Bin/pygobject",
                             "create_shared_zip": False,
                             "packages": ["gi"],
                             }},
      executables=[Executable(script="hello_pygobject.py",
                              targetName="hello",
                              appendScriptToExe=True,
                              )]
      )

Dangelo

Well done for finding it. Sorry I wasn't more help :-) – Plumbiferous

@Plumbiferous Be proud, you got me indirectly to the right direction :-). – Dangelo