Bug 430347

Summary: virt-manager crashing after pygtk2 update
Product: Red Hat Enterprise Linux 5 Reporter: Ian Pilcher <ipilcher>
Component: pygtk2Assignee: Matthew Barnes <mbarnes>
Status: CLOSED ERRATA QA Contact: desktop-bugs <desktop-bugs>
Severity: high Docs Contact:
Priority: medium    
Version: 5.1CC: cward, dyin, sputhenp, tis, xen-maint
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2008-0079 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-30 15:13:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Core file from virt-manager crash
none
Fix the broken reference counting for sort callbacks none

Description Ian Pilcher 2008-01-26 17:13:17 UTC
Description of problem:
After installing the latest pygtk2 (and pygtk2-libglade) from the RHEL 5
Fasttrack channel, virt-manager crashes (Segmentation fault) almost immediately
after statring.

Version-Release number of selected component (if applicable):
pygtk2-2.10.1-11.el5


How reproducible:
100%

Steps to Reproduce:
1.  Install pygtk2-2.10.1-11.el5 and pygtk2-libglade-2.10.1-11.el5
2.  Start virt-manager
  
Actual results:
Segmentation fault

Expected results:
virt-manager should run

Additional info:
System is fully-updated RHEL 5

Comment 1 Ian Pilcher 2008-01-26 17:13:18 UTC
Created attachment 293053 [details]
Core file from virt-manager crash

Comment 2 Daniel Berrangé 2008-01-26 18:25:55 UTC
Can you install the -debuginfo RPMs for the exact matching version+releases of
gtk2, glib2, glibc, python, pygtk2 and virt-manager and use gdb to get the stack
trace for that corefile - i can't do it myself because I don't know the full
version+release of all the RPMs in your stack

Basically after installing the debuginfo, do:

gdb python core.XXXX
(gdb) thread apply all backtrace

And attach the output to this BZ.


Comment 3 Matthew Barnes 2008-01-26 18:43:58 UTC
Comment on attachment 293053 [details]
Core file from virt-manager crash

Fixing MIME Type of core file.

Comment 4 Daniel Berrangé 2008-01-26 19:57:17 UTC
The patch pygtk-2.10.1-boxed-unref-shared.patch  from the Fasttrack errata
pygtk2-2.10.1-11.el5 has utterly screwed up the reference counting on the tree
view sort callbacks.

@@ -1124,13 +1125,14 @@ pygtk_tree_sortable_sort_cb(GtkTreeModel
     py_iter2 = pyg_boxed_new(GTK_TYPE_TREE_ITER, iter2,  FALSE, FALSE);
 
     if (cunote->data) {
-        retobj = PyEval_CallFunction(cunote->func, "(NNNO)", py_model,
+        retobj = PyEval_CallFunction(cunote->func, "(OONO)", py_model,
                                      py_iter1, py_iter2, cunote->data);
     } else {
-        retobj = PyEval_CallFunction(cunote->func, "(NNN)", py_model,
+        retobj = PyEval_CallFunction(cunote->func, "(OON)", py_model,
                                      py_iter1, py_iter2);
     }
-
+    pygtk_boxed_unref_shared(py_iter1);
+    pygtk_boxed_unref_shared(py_iter2);
     if (retobj)
         ret = PyInt_AsLong(retobj);
     if (PyErr_Occurred()) {


Note the change in format specifier to PyEval_CallFunction. It changes the
py_model arg so that the ref count is incremented - this is now a memory leak
because it is never decremented again. It leaves py_iter2 without having its
ref-count incremented, and then explicitly decrements it causing the object to
be free'd when it is still in use. ergo SEGV from random data corruption shortly
thereafter.

If I comment out the tree view sort code in virt-manager it stops crashes, just
confirming that this patch is the root cause.

You can further confirm that the format arg to PyEval_CallFunction is bogus by
comparing with the code in Fedora 8's version of PyGTK. So the backport done in
bug 237077 comment #7 is flawed.


Comment 5 Daniel Berrangé 2008-01-26 20:00:32 UTC
Created attachment 293061 [details]
Fix the broken reference counting for sort callbacks

With this patch applied the reference counting now matches that done by
upstream PyGTK and virt-manager no longer crashes.

Comment 6 Daniel Berrangé 2008-01-26 20:02:59 UTC
Further it would appear that the original patch from bug 237077 is potentially
incomplete because it didn't add the pygtk_boxed_unref_shared() calls to the
pygtk_tree_foreach_marshal() method. This doesn't affect virt-manager though -
just an FYI i noticed while diff'ing the RHEL5 vs F8   gtktreeview.override file.

Comment 8 Ian Pilcher 2008-01-26 20:10:05 UTC
(In reply to comment #2)

Requested backtrace (needed or not):

Thread 1 (process 4009):
#0  _PyLong_AsScaledDouble (vv=0xb7916b90, exponent=0xbfef2aec) at
Objects/longobject.c:633
#1  0x00cfee6f in PyLong_AsDouble (vv=0xb7916b90) at Objects/longobject.c:661
#2  0x00cf10f3 in convert_to_double (v=0xbfef2b50, dbl=0xbfef2b38) at
Objects/floatobject.c:284
#3  0x00cf2dcb in float_classic_div (v=0xb7916b90, w=0x939894c) at
Objects/floatobject.c:649
#4  0x00cdf502 in binary_op1 (v=0xb7916b90, w=0x939894c, op_slot=12) at
Objects/abstract.c:377
#5  0x00cdff7b in binary_op (v=0xb7916b90, w=0x6bc00001, op_slot=14387624,
op_name=0xd7e5ee "/") at Objects/abstract.c:422
#6  0x00d41b33 in PyEval_EvalFrame (f=0x91a9644) at Python/ceval.c:1060
#7  0x00d4252f in PyEval_EvalFrame (f=0x91a983c) at Python/ceval.c:3645
#8  0x00d43c68 in PyEval_EvalCodeEx (co=0xb7a4d820, globals=0xb7a3b24c,
locals=0x0, args=0xb78b2258, argcount=2, kws=0x0, kwcount=0,
    defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736
#9  0x00cf5c6a in function_call (func=0xb7a50dbc, arg=0xb78b224c, kw=0x0) at
Objects/funcobject.c:548
#10 0x00cddd57 in PyObject_Call (func=0xdb89a8, arg=0xb78b224c, kw=0x0) at
Objects/abstract.c:1795
#11 0x00ce4358 in instancemethod_call (func=0xb78b83c4, arg=0xb78b224c, kw=0x0)
at Objects/classobject.c:2447
#12 0x00cddd57 in PyObject_Call (func=0xdb89a8, arg=0xb78b294c, kw=0x0) at
Objects/abstract.c:1795
#13 0x00d3d48c in PyEval_CallObjectWithKeywords (func=0xb78b83c4,
arg=0xb78b294c, kw=0x0) at Python/ceval.c:3430
#14 0x00cde8dc in PyObject_CallObject (o=0xb78b83c4, a=0xb78b294c) at
Objects/abstract.c:1786
#15 0x00e2ee77 in g_param_spec_ref@plt () from
/usr/lib/python2.4/site-packages/gtk-2.0/gobject/_gobject.so
#16 0x00265f0b in IA__g_closure_invoke (closure=0x9525578,
return_value=0xbfef3538, n_param_values=1, param_values=0x9561250,
    invocation_hint=0xbfef342c) at gclosure.c:490
#17 0x00276e83 in signal_emit_unlocked_R (node=0x92fc060, detail=0,
instance=0x93e7e30, emission_return=0xbfef3538,
    instance_and_params=0x9561250) at gsignal.c:2438
#18 0x002786e9 in IA__g_signal_emitv (instance_and_params=0x9561250,
signal_id=9, detail=0, return_value=0xbfef3538) at gsignal.c:2109
#19 0x00e24e69 in g_param_spec_ref@plt () from
/usr/lib/python2.4/site-packages/gtk-2.0/gobject/_gobject.so
#20 0x00d0845d in PyCFunction_Call (func=0xb78aa34c, arg=0xb7a9bccc, kw=0x0) at
Objects/methodobject.c:108
#21 0x00d429bd in PyEval_EvalFrame (f=0x9248dd4) at Python/ceval.c:3563
#22 0x00d4252f in PyEval_EvalFrame (f=0x93d8f84) at Python/ceval.c:3645
#23 0x00d43c68 in PyEval_EvalCodeEx (co=0xb7a32360, globals=0xb7a300b4,
locals=0x0, args=0x951f3e4, argcount=1, kws=0x951f3e8, kwcount=0,
    defs=0xb7a47958, defcount=1, closure=0x0) at Python/ceval.c:2736
#24 0x00d42426 in PyEval_EvalFrame (f=0x951f28c) at Python/ceval.c:3656
#25 0x00d4252f in PyEval_EvalFrame (f=0x9140a14) at Python/ceval.c:3645
#26 0x00d43c68 in PyEval_EvalCodeEx (co=0xb7a96aa0, globals=0xb7a98d74,
locals=0x0, args=0xb7a9bcf8, argcount=1, kws=0x0, kwcount=0,
    defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736
#27 0x00cf5c6a in function_call (func=0xb78b302c, arg=0xb7a9bcec, kw=0x0) at
Objects/funcobject.c:548
#28 0x00cddd57 in PyObject_Call (func=0xdb89a8, arg=0xb7a9bcec, kw=0x0) at
Objects/abstract.c:1795
#29 0x00ce4358 in instancemethod_call (func=0xb79dac5c, arg=0xb7a9bcec, kw=0x0)
at Objects/classobject.c:2447
#30 0x00cddd57 in PyObject_Call (func=0xdb89a8, arg=0xb7ed602c, kw=0x0) at
Objects/abstract.c:1795
#31 0x00d3d48c in PyEval_CallObjectWithKeywords (func=0xb79dac5c,
arg=0xb7ed602c, kw=0x0) at Python/ceval.c:3430
#32 0x00cde8dc in PyObject_CallObject (o=0xb79dac5c, a=0xb7ed602c) at
Objects/abstract.c:1786
#33 0x00e1d00a in g_param_spec_ref@plt () from
/usr/lib/python2.4/site-packages/gtk-2.0/gobject/_gobject.so
#34 0x004de916 in g_timeout_dispatch (source=0x93e3ec8, callback=0x6bc00001,
user_data=0xb78b22ec) at gmain.c:3422
#35 0x004de342 in IA__g_main_context_dispatch (context=0x92615c8) at gmain.c:2045
#36 0x004e131f in g_main_context_iterate (context=0x92615c8, block=1,
dispatch=1, self=0x923a558) at gmain.c:2677
#37 0x004e16c9 in IA__g_main_loop_run (loop=0x9523180) at gmain.c:2881
#38 0x04e91b24 in IA__gtk_main () at gtkmain.c:1001
#39 0x0038c5d0 in _wrap_gtk_main (self=0x0) at ./gtk.override:1132
#40 0x00d4273a in PyEval_EvalFrame (f=0x93f15b4) at Python/ceval.c:3547
#41 0x00d4252f in PyEval_EvalFrame (f=0x9157a5c) at Python/ceval.c:3645
#42 0x00d43c68 in PyEval_EvalCodeEx (co=0xb7e9bea0, globals=0xb7eed824,
locals=0xb7eed824, args=0x0, argcount=0, kws=0x0, kwcount=0,
    defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736
#43 0x00d43cf3 in PyEval_EvalCode (co=0xb7e9bea0, globals=0xb7eed824,
locals=0xb7eed824) at Python/ceval.c:484
#44 0x00d60998 in run_node (n=<value optimized out>, filename=<value optimized
out>, globals=0xb7eed824, locals=0xb7eed824, flags=0xbfef48d4)
    at Python/pythonrun.c:1265
#45 0x00d620a8 in PyRun_SimpleFileExFlags (fp=0x9122008, filename=0xbfef5bcc
"/usr/share/virt-manager/virt-manager.py", closeit=1,
    flags=0xbfef48d4) at Python/pythonrun.c:860
#46 0x00d6278a in PyRun_AnyFileExFlags (fp=0x9122008, filename=0xbfef5bcc
"/usr/share/virt-manager/virt-manager.py", closeit=1,
    flags=0xbfef48d4) at Python/pythonrun.c:664
#47 0x00d69185 in Py_Main (argc=1, argv=0xbfef49a4) at Modules/main.c:493
#48 0x08048582 in main (argc=3, argv=0xdb8aa0) at Modules/python.c:23

Comment 11 RHEL Program Management 2008-01-28 16:37:43 UTC
This bugzilla was reviewed by QE as a non-FasTrack request.
It has since been proposed for FasTrack. The qa_ack has 
been reset. QE needs to re-review this bugzilla for FasTrack.

Comment 13 Matthew Barnes 2008-01-28 20:03:12 UTC
For the record, these are the upstream changes applied to pygtk2-2.10.1-11.el5
which introduced the reference counting problem that crashes virt-manager.

http://svn.gnome.org/viewvc/pygtk?view=revision&revision=2778

The problem was subsequently corrected upstream.  The changes are consistent
with Daniel's patch.

http://svn.gnome.org/viewvc/pygtk?view=revision&revision=2876

Comment 14 Matthew Barnes 2008-01-28 20:21:33 UTC
Second change set applied to pygtk2-2.10.1-12.el5.

Comment 16 Tuomo Soini 2008-01-29 07:37:30 UTC
This same bug affects setroubleshoot causing crash.

Comment 17 Matthew Barnes 2008-01-30 03:25:39 UTC
*** Bug 430837 has been marked as a duplicate of this bug. ***

Comment 22 errata-xmlrpc 2008-01-30 15:13:25 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0079.html