Below well-commented program shows how the bug comes about. It can be compiled with
$ cc test.c -o test -lpython2.4 `pkg-config --cflags --libs glib-2.0`
Note that the same bug is present in the gtk module as well, I just
didn't bother to make the program flexible enough to show that too.
The problem is that all of the modules install a log handler into glib
for their log domain, but don't detach it again when the python
interpreter is shut down. This causes havoc when the program that embeds
python tries to do something with pango/gtk/... that causes a warning.
Here's the program:
#include <python2.4/Python.h>
/* we fake pango warnings so we don't
* need to actually call pango with
* something that'll create a warning
*/
#define G_LOG_DOMAIN "Pango"
#include <glib-2.0/glib.h>
int main() {
/* start up python interpreter */
Py_Initialize();
/* let's fake a pango warning now.
* it should come up on stderr.
*/
g_warning("faked pango warning (1)");
/* let's use pango from the embedded
* python interpreseter. we only import
* and don't actually use it.
*/
PyRun_SimpleString("import pango");
/* for kicks, throw in some python code
* to show that this still works */
PyRun_SimpleString("print pango.parse_markup.__doc__");
/* another fake warning, note that is
* printed through python now! */
g_warning("faked pango warning (2)");
/* now let's get rid of the python state, we
* no longer need the python interpreter...
*/
Py_Finalize();
/* KABOOM. Obviously the pango module forgets
* to unhook the log handler and tries to call
* into python even though that's long gone. */
g_warning("faked pango warning (3)");
}
signature.asc
Description: This is a digitally signed message part
