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 642527 - ref_count problems with gtk.Toolbars
ref_count problems with gtk.Toolbars
Status: RESOLVED FIXED
Product: reinteract
Classification: Other
Component: general
unspecified
Other Linux
: Normal minor
: ---
Assigned To: reinteract-maint
reinteract-maint
Depends on:
Blocks:
 
 
Reported: 2011-02-17 04:28 UTC by Robert Schroll
Modified: 2011-09-04 21:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Remove use of <signal>: 'override' (5.15 KB, patch)
2011-09-04 21:23 UTC, Owen Taylor
committed Details | Review

Description Robert Schroll 2011-02-17 04:28:41 UTC
When a widget embedded in a worksheet that includes a gtk.Toolbar is unrealized, it may print to the terminal, "Warning: g_object_ref: assertion `object->ref_count > 0' failed".  When such a worksheet is close, the warning may be repeated, or the error "GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed" may be printed.

I don't know if this is a problem with Reinteract or with (py)GTK.  I have been unable to replicate the problem with a simple pyGTK app, so it's not something obviously wrong in GTK.  This behavior is seen in at least two version of GTK; more details here: http://groups.google.com/group/reinteract/browse_thread/thread/5fa93db725fb529e

----Test case worksheet----
import gtk
from reinteract.custom_result import CustomResult

class Toolbar(CustomResult):

    def create_widget(self):
        return gtk.Toolbar()

if True:
    Toolbar()
1
----Test case worksheet----
After executing the worksheet, edit and re-execute the Toolbar() line, or simply indent the final line, to cause an unrealize of the gtk.Toolbar.  This usually triggers the warning about the ref_count, though usually only the first time.
Comment 1 Owen Taylor 2011-09-04 21:22:57 UTC
See bug 658200 for the underlying GTK+ problem, but it turns out there is a good "workaround" - why we trigger it and nobody else is triggering it is that custom_result.py has:

     __gsignals__ = {
        'parent-set': 'override',
     }

and this causes the 'parent-set' signal to be globally hooked and emitted in cases where it would otherwise be short-circuited. The use of 'override' hasn't been necessary since ~2005, so we can just remove it. Will attach then push a patch.
Comment 2 Owen Taylor 2011-09-04 21:23:15 UTC
Created attachment 195642 [details] [review]
Remove use of <signal>: 'override'

Using 'override' in __gsignals__ has not been necessary since around 2005 when
virtual function support was added to pygtk. It also has a negative effect in
that it causes a "class closure" to be used for the signal everywhere in the
program, even for widgets that aren't visible to Python, slowing things down
and in some cases triggering bugs in GTK+.

We keep empty __gsignals__ arrays because we still need to have the types
registered with GObject for the virtual function support to work; this is
forced when a __gsignals__ array is present.
Comment 3 Owen Taylor 2011-09-04 21:23:34 UTC
Attachment 195642 [details] pushed as 264b9bc - Remove use of <signal>: 'override'