| 2012-11-13 14:27:10 |
Daniel Narvaez |
bug |
|
|
added bug |
| 2012-11-13 15:08:54 |
Martin Pitt |
nominated for series |
|
Ubuntu Quantal |
|
| 2012-11-13 15:08:54 |
Martin Pitt |
bug task added |
|
pygobject (Ubuntu Quantal) |
|
| 2012-11-13 15:08:54 |
Martin Pitt |
nominated for series |
|
Ubuntu Raring |
|
| 2012-11-13 15:08:54 |
Martin Pitt |
bug task added |
|
pygobject (Ubuntu Raring) |
|
| 2012-11-13 15:09:12 |
Martin Pitt |
pygobject (Ubuntu Raring): status |
New |
Fix Released |
|
| 2012-11-13 15:19:59 |
Martin Pitt |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2012-11-13 15:20:14 |
Martin Pitt |
pygobject (Ubuntu Quantal): status |
New |
In Progress |
|
| 2012-11-13 15:22:51 |
Martin Pitt |
description |
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 |
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. |
|
| 2012-11-13 15:25:22 |
Martin Pitt |
pygobject (Ubuntu Quantal): assignee |
|
Martin Pitt (pitti) |
|
| 2012-11-28 05:53:02 |
Martin Pitt |
description |
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. |
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 |
|
| 2012-11-28 08:08:25 |
Martin Pitt |
description |
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 |
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.
See also bug 1083694 which is the same hang for software-center; this also has a test case. |
|
| 2012-11-29 20:07:27 |
Brian Murray |
pygobject (Ubuntu Quantal): status |
In Progress |
Fix Committed |
|
| 2012-11-29 20:07:32 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2012-11-29 20:07:35 |
Brian Murray |
tags |
|
verification-needed |
|
| 2012-11-30 12:06:04 |
Daniel Narvaez |
tags |
verification-needed |
verification-done |
|
| 2012-12-10 14:12:24 |
Colin Watson |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2012-12-10 14:13:25 |
Launchpad Janitor |
pygobject (Ubuntu Quantal): status |
Fix Committed |
Fix Released |
|
