GNOME Bugzilla – Bug 636656
glib.main_context_default() causes immediate segfault
Last modified: 2011-01-17 14:50:56 UTC
Hi, I'm opening here a bugreport that have been reported on Debian BTS: "[crybaby /tmp/mdw]cat break.py import glib print glib.main_context_default() [crybaby /tmp/mdw]python break.py 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, &PyGMainContext_Type); 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: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580791
*** Bug 587265 has been marked as a duplicate of this bug. ***
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.
The GLib module should probably have a public API instead of a private one, as in the GObject module.
Comment on attachment 177310 [details] [review] Move pyglib_{main_context, option_context, option_group}_new into _PyGLib_API looks good to me
Attachment 177310 [details] pushed as 8ceef79 - Move pyglib_{main_context, option_context, option_group}_new into _PyGLib_API