In a complex application, I'm seeing crashes when the destroy notify of GLib.child_watch_add is called.
#0 0x00000000004b5c78 in tupledealloc.24592 (op=0x316dc80)
at ../Objects/tupleobject.c:218
#1 0x00002b7c1553abc7 in child_watch_dnotify (data=0x345a320)
at /build/buildd/pygobject-3.4.0/gi/_glib/glibmodule.c:355
#2 0x00002b7c1409c108 in g_source_callback_unref (cb_data=0x3475f40)
at /build/buildd/glib2.0-2.34.0/./glib/gmain.c:1457
#3 g_source_callback_unref (cb_data=0x3475f40)
at /build/buildd/glib2.0-2.34.0/./glib/gmain.c:1449
#4 0x00002b7c1409c70a in g_source_destroy_internal (source=source@entry=
0x3471370, context=context@entry=0x1d08a30, have_lock=have_lock@entry=1)
at /build/buildd/glib2.0-2.34.0/./glib/gmain.c:1123
#5 0x00002b7c1409eb00 in g_main_dispatch (context=0x1d08a30)
at /build/buildd/glib2.0-2.34.0/./glib/gmain.c:2739
In a complex application, I'm seeing crashes when the destroy notify of GLib.child_ watch_add is called.
#0 0x00000000004b5c78 in tupledealloc.24592 (op=0x316dc80) tupleobject. c:218 buildd/ pygobject- 3.4.0/gi/ _glib/glibmodul e.c:355 callback_ unref (cb_data=0x3475f40) buildd/ glib2.0- 2.34.0/ ./glib/ gmain.c: 1457 callback_ unref (cb_data=0x3475f40) buildd/ glib2.0- 2.34.0/ ./glib/ gmain.c: 1449 destroy_ internal (source= source@ entry= context@ entry=0x1d08a30 , have_lock= have_lock@ entry=1) buildd/ glib2.0- 2.34.0/ ./glib/ gmain.c: 1123 buildd/ glib2.0- 2.34.0/ ./glib/ gmain.c: 2739
at ../Objects/
#1 0x00002b7c1553abc7 in child_watch_dnotify (data=0x345a320)
at /build/
#2 0x00002b7c1409c108 in g_source_
at /build/
#3 g_source_
at /build/
#4 0x00002b7c1409c70a in g_source_
0x3471370, context=
at /build/
#5 0x00002b7c1409eb00 in g_main_dispatch (context=0x1d08a30)
at /build/
The problem has been fixed upstream
http:// git.gnome. org/browse/ pygobject/ commit/ ?h=pygobject- 3-4&id= a06e0d021d74c95 cd517abb3e6ef5f f0037de679