** Description changed: 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 The problem has been fixed upstream http://git.gnome.org/browse/pygobject/commit/?h=pygobject-3-4&id=a06e0d021d74c95cd517abb3e6ef5ff0037de679 REGRESSION POTENTIAL: Very low. This just adds locking around the reference handling to avoid race conditions with concurrent access. pyglib_gil_state_{ensure,release}() is used all over the place in pygobject, but it was forgotten in this particular function. SRU TEST CASE: This is rather hard to reproduce, as it is a race condition in a multi-threaded program. As Daniel can reproduce it rather well, I suggest to ask him to verify the SRU. + + Michael Vogt proposed a test case: + - open software-center + - go to a app with reviews + - click on "useful": "YES" + - verify that it takes a long time
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1078297 Title: Crashes with GLib.child_watch_add To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pygobject/+bug/1078297/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
