GNOME Bugzilla – Bug 653181
Interfaces taking ambiguous GValues crashes marshaller with malloc: memory corruption
Last modified: 2011-06-28 16:02:28 UTC
Created attachment 190457 [details] gdb dump reflecting the bug in gtk3 code Can be reproduced on the invoke-rewrite branch. Attaching the IRC log for more details: -- <J5> how does malloc cause memory corruption? I'm guessing the corruption is somewhere else in a dealloc <J5> alex3f, your storage types look wrong <J5> there a bunch of warnings about conversions of GObjects to Pyobjects <alex3f> I see them <J5> alex3f, can you point me to the code where you set up your treemodel? <alex3f> http://bazaar.launchpad.net/~mmcg069/software-center/gtk3again/view/head:/softwarecenter/ui/gtk3/models/viewstore.py#L57 <J5> alex3f, ya those should be the types you are actually storing. <J5> not PYOBJECT hmm, I'm guessing they did that to save on the conversion * J5 checks the override ... <J5> alex3f, now I remember why we can't do that. We assume if it is a GObject we need to marshal it <alex3f> hm <J5> There is no way to mark the object as needing to be marshalled as a pyobject. PyGTK avoids this because they hardcode the marshaller for treemodels we could fix this by adding a PyObject wrapper object which wraps the pyobject pointer in the overrides and tells the marshaller that it should marshalled as the raw pyobject <alex3f> I'm not sure I'm following <J5> class PyGIPyObjectWrapper(object): def __init__(self, pyobj): self._pyobj = pyobj <J5> of course that would have to be coded in C <J5> then the override would wrap the pyobject in the wrapper <J5> and when the marshaller sees PyGIPyObjectWrapper object it would pass the internal pyobject instead of marshalling it <alex3f> I see <J5> alex3f, can you file a bug on that. I won't get to it for a bit. For now you should change the types to reflect the actual GTypes <alex3f> let me get it right this is a bug in Gtk.TreeModel only? or affects the marshalling of all PYOBJECTs <J5> it is a bug in any interface that takes ambiguous GValues the nice things about the treemodel is we can grab the column type but only at the override level. GI still has to guess at what type to marshal because it has no dependencies on Gtk adding the python wrapper in the override give the marshaller enough info to know to marshal the type as the raw python object --
As a follow up, after changing the TreeStore column type to the actual types, -- class ViewStore(Gtk.TreeStore): @@ -54,12 +53,20 @@ def __init__(self, view_manager, datadir, db, cache, icons): Gtk.TreeStore.__init__(self) + """ self.set_column_types((GObject.TYPE_PYOBJECT, # COL_ICON str, # COL_NAME GObject.TYPE_PYOBJECT, # COL_ACTION GObject.TYPE_PYOBJECT, # COL_CHANNEL str, # COL_BUBBLE_TEXT )) # must match columns above + """ + self.set_column_types((GdkPixbuf.Pixbuf, + str, + str, + SoftwareChannel, + str, + )) self.view_manager = view_manager self.icons = icons self.datadir = datadir -- it still crashes with *** glibc detected *** /usr/bin/python: malloc(): memory corruption: 0x0930c958 ***
Created attachment 190505 [details] sc-gtk3-invoke-rewrite-malloc-traceback.txt traceback for the malloc problem
Created attachment 190506 [details] sc-gtk3-master-normal-output.txt the normal output, as seen when running pygobject from master.
This seems to be a 32bit issue. I was able to reproduce in the tests on a 32bit virt instance. It also seems to be related to strings so my guess is we are double freeing somewhere.
May have fixed it by using g_slice for GValues. We can't trust the struct size given back by GI for GValues.
ping, can you test with the latest PyGObject from the invoke-rewrite branch?
Tested it, the bug doesn't reproduce with latest invoke-rewrite pygobject :)
Hazah!! Closing. Thanks for helping me track this down and bearing with the process of porting to a new technology. Please file bugs as you find them and feel free to ping me.
Oh and I am going to work on Python objects in GValues. Luckily GValues are GLib structures so I can special case the marshallers to look at the type when marshalling.