After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 653181 - Interfaces taking ambiguous GValues crashes marshaller with malloc: memory corruption
Interfaces taking ambiguous GValues crashes marshaller with malloc: memory co...
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: introspection
Git master
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2011-06-22 17:19 UTC by Alex Eftimie
Modified: 2011-06-28 16:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gdb dump reflecting the bug in gtk3 code (50.37 KB, text/plain)
2011-06-22 17:19 UTC, Alex Eftimie
Details
sc-gtk3-invoke-rewrite-malloc-traceback.txt (106.21 KB, text/plain)
2011-06-23 10:00 UTC, Alex Eftimie
Details
sc-gtk3-master-normal-output.txt (3.31 KB, text/plain)
2011-06-23 10:01 UTC, Alex Eftimie
Details

Description Alex Eftimie 2011-06-22 17:19:36 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
--
Comment 1 Alex Eftimie 2011-06-23 09:59:04 UTC
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 ***
Comment 2 Alex Eftimie 2011-06-23 10:00:14 UTC
Created attachment 190505 [details]
sc-gtk3-invoke-rewrite-malloc-traceback.txt

traceback for the malloc problem
Comment 3 Alex Eftimie 2011-06-23 10:01:02 UTC
Created attachment 190506 [details]
sc-gtk3-master-normal-output.txt

the normal output, as seen when running pygobject from master.
Comment 4 johnp 2011-06-23 14:09:22 UTC
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.
Comment 5 johnp 2011-06-24 18:23:06 UTC
May have fixed it by using g_slice for GValues.  We can't trust the struct size given back by GI for GValues.
Comment 6 johnp 2011-06-27 16:26:15 UTC
ping, can you test with the latest PyGObject from the invoke-rewrite branch?
Comment 7 Alex Eftimie 2011-06-28 09:15:43 UTC
Tested it, the bug doesn't reproduce with latest invoke-rewrite pygobject :)
Comment 8 johnp 2011-06-28 16:01:11 UTC
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.
Comment 9 johnp 2011-06-28 16:02:28 UTC
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.