After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 636656 - glib.main_context_default() causes immediate segfault
glib.main_context_default() causes immediate segfault
Product: pygobject
Classification: Bindings
Component: general
Git master
Other Linux
: Normal normal
: ---
Assigned To: Simon van der Linden
Python bindings maintainers
: 587265 (view as bug list)
Depends on:
Reported: 2010-12-06 23:21 UTC by Laurent Bigonville
Modified: 2011-01-17 14:50 UTC
See Also:
GNOME target: ---
GNOME version: ---

Move pyglib_{main_context, option_context, option_group}_new into _PyGLib_API (9.02 KB, patch)
2010-12-31 17:47 UTC, Simon van der Linden
committed Details | Review

Description Laurent Bigonville 2010-12-06 23:21:29 UTC

I'm opening here a bugreport that have been reported on Debian BTS:

"[crybaby /tmp/mdw]cat
import glib
print glib.main_context_default()
[crybaby /tmp/mdw]python
Segmentation fault

What's going on?  glib/pyglib.c seems to be somewhat confused about how
it's getting hold of its type objects.  Rather than just using the handy
PyGMainContext_Type structure lying around, it says

static PyTypeObject *_PyGMainContext_Type;
#define PyGMainContext_Type (*_PyGMainContext_Type)

and relies on pyglib_init() saying

    _PyGMainContext_Type = (PyTypeObject*)PyObject_GetAttrString(glib, "MainContext");

to initialize this -- but /doesn't call pyglib_init() anywhere/.  Now,
when pyglib_main_context_new says

    self = (PyGMainContext *)PyObject_NEW(PyGMainContext,

it's using the macro, which indirects through _PyGMainContext_Type,
which is still a null pointer.  Result: segfault.

Workaround: import gobject, which calls pyglib_init() and sets the
pointer up.

Proper fix: either initialize the pointers properly, or at least put
pyglib_main_context_new in a different source file.

This bug is also in Ubuntu Lucid and Maemo Fremantle.

Orgiginal bugreport:
Comment 1 Simon van der Linden 2010-12-31 16:11:56 UTC
*** Bug 587265 has been marked as a duplicate of this bug. ***
Comment 2 Simon van der Linden 2010-12-31 17:47:54 UTC
Created attachment 177310 [details] [review]
Move pyglib_{main_context, option_context, option_group}_new into _PyGLib_API

_PyG{MainContext, OptionContext, and OptionGroup_Type} were not be initialized
when used inside the glib module, since pyglib_init is not called.

pyglib.c is compiled as a stand-alone library loaded by the _glib module that
declares the above-mentioned types. Hence, they cannot be accessed by the
former. This patch moves the functions that need those symbols into the
glib._glib module and exports them to the pyglib library through _PyGLib_API.
Comment 3 Simon van der Linden 2010-12-31 17:51:30 UTC
The GLib module should probably have a public API instead of a private one, as in the GObject module.
Comment 4 johnp 2011-01-04 16:59:24 UTC
Comment on attachment 177310 [details] [review]
Move pyglib_{main_context, option_context, option_group}_new into _PyGLib_API

looks good to me
Comment 5 Simon van der Linden 2011-01-17 14:50:52 UTC
Attachment 177310 [details] pushed as 8ceef79 - Move pyglib_{main_context, option_context, option_group}_new into _PyGLib_API