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 708676 - G_VALUE_HOLDS_INT failed with GtkEditable signal
G_VALUE_HOLDS_INT failed with GtkEditable signal
Status: RESOLVED DUPLICATE of bug 644927
Product: pygobject
Classification: Bindings
Component: general
3.10.x
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on: 644927
Blocks:
 
 
Reported: 2013-09-24 12:11 UTC by Christoph Reiter (lazka)
Modified: 2014-05-03 01:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christoph Reiter (lazka) 2013-09-24 12:11:20 UTC
The following triggers a warning with 3.10 (GTK+ 3.8.4, glib 2.37.93):

a.py:5: Warning: g_value_get_int: assertion 'G_VALUE_HOLDS_INT (value)' failed
  entry.set_text("bar")

#############################

from gi.repository import Gtk
entry = Gtk.Entry()
entry.connect("insert-text", lambda *x: None)
entry.set_text("bar")
Comment 1 Christoph Reiter (lazka) 2013-10-18 15:36:38 UTC
c07404461b126206e369270b56e613f81369c70a is the first bad commit
commit c07404461b126206e369270b56e613f81369c70a
Author: Daniel Drake <dsd@laptop.org>
Date:   Mon Mar 18 16:08:09 2013 -0600

    Optimize signal lookup in gi repository
    
    Now that we have GSignalQuery results available to us when connecting
    signals, we already know which GType implements the signal in question.
    
    Therefore there is no need to traverse the class parent hierarchy
    looking for this, which takes a considerable amount of CPU time.
    
    There is also no need to canonicalize the signal name; both before
    and after this patch, by the time we reach this point we have already
    successfully looked up the signal name as presented from Python.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=696143

:040000 040000 b8b56e1284d07264d633366ae0a67654e30436a0 415b81c80eda77e36dd77facd43298a6001620d3 M	gi
Comment 2 Simon Feltman 2013-10-19 10:00:25 UTC
How serious of a bug is this beyond it just being a warning? The in the commit boils down to signals defined on interfaces are now marshaled using GI information instead of a best guess based on GValues.

+    else if (GI_IS_INTERFACE_INFO (info))
+        signal_info = g_interface_info_find_signal ((GIInterfaceInfo *) info,
+                                                    signal_name);

The problem is that this exposes bug 644927 because marshaling out/inout args in signals is not working. So if we can deal with this just being a warning, I think it would be a better idea focus effort on fixing bug 644927 (as opposed to backing interface support out).
Comment 3 Christoph Reiter (lazka) 2013-12-11 20:27:32 UTC
Is there some way to suppress this warning?
Comment 4 Simon Feltman 2014-04-28 06:34:11 UTC
(In reply to comment #3)
> Is there some way to suppress this warning?

I think this is a GTK+ assertion translated into a Python warning by pygi, so you should be able to use Python warning suppression, something like:

  warnings.filterwarnings('ignore', '.*g_value_get_int.*set_text.*', Warning)

or

  with warnings.catch_warnings():
    warnings.simplefilter("ignore")
    entry.set_text('bar')
Comment 5 Christoph Reiter (lazka) 2014-04-30 15:23:29 UTC
Thanks Simon, worked perfectly.

I think this can be closed.
Comment 6 Simon Feltman 2014-05-03 01:55:46 UTC

*** This bug has been marked as a duplicate of bug 644927 ***