Mysterious GObject warning: assertion `G_IS_OBJECT (object)' failed

Question

I have a warning when I run my GTK (Python GObject introspection) application and I can't figure out its source. When the application is loading and I'm populating a GtkListStore, after the very first time I append a row, I get the following warning:

/usr/lib/python2.7/site-packages/gi/types.py:44: Warning: g_object_set_qdata: assertion `G_IS_OBJECT (object)' failed
  return info.invoke(*args)

The rest of the rows append without any further warnings. In fact, it's always only raised once, always on the first item to be appended. But, the actual contents of the row don't seem to matter; it raise the warning no matter what. When the program finishes loading, all of the rows seem to be ok when I browse them in the TreeView.

My list store looks like this:

self.list_store = Gtk.ListStore(bool, str, str, str, str, str, str,
                                str, str, str, str, GdkPixbuf.Pixbuf,
                                str, str, str, object, Pango.Weight)

The last few columns are hidden from the associated GtkTreeView, but the warning occurs before the TreeView is created, so I'm sure it's coming from the ListStore.Needless to say, I'm sure that all the rows I'm passing are in the correct format since, like I said, the warning is always raised after the first row, no matter which row I add first.

Does anyone have any idea what could be causing this? It's not preventing my application from running, so it's not an emergency, but I'd rather not have it spitting out warnings for the end user.

---

Edit: I confirmed using Python's -W all commandline argument that the warning is actually being raised for all rows.

I tried stepping into the append() method using pdb but, interstingly, it gets stuck in a loop in the gi code when it tries setting the value of the column containing the GdkPixbuf, so I never actually see the warning raised when debugging the program. My guess is that the Pixbuf is causing the problem, but I have no idea how to change it to get rid of the warning. The Pixbuf renders correctly in the TreeView, so I'm not sure what is going on.

Impale

I think by default Python silences repeated warnings of the same type - so just because you only see it once doesn't mean it's only raised once. – Episcopal

Hm ok, that's a bit reassuring.My guess then is that it's either not liking the Pixbuf or the object in there but I have no idea how else I could specify it. – Impale

Did you try looking at a backtrace? – Brenneman

Ok, first of all, by launching the application with Python's -W all commandline argument, I confirmed that the warning is indeed happening for each row being added. – Impale

@ptomato: I guess I'm new to stack traces.The traceback module doesn't seem to help since it's a warning and not an exception; I can't seem to capture the stack in which the warning occurs. I could use the warnings module to force warnings to be raised as exceptions, but this code is happening in a thread and warnings is not thread-safe. Any tips would be appreciated. – Impale

@Brandon, I didn't realize warnings isn't thread-safe. But wouldn't the exception still get raised? – Brenneman

Since warnings alters the global context, I wouldn't risk it. – Impale

Answer 1

Taking a wild guess at this...

PyGTK seems to be rather talented at creating weird errors - especially ones that send us on wild goose chases. I've fought six or seven different such errors that, in the end, are just masking another issue...sometimes even an unrelated one.

All the same, running a Google search shows that this has been documented, though perhaps not solved...? (One such example: https://bugs.launchpad.net/ubuntu/+source/jockey/+bug/814991)

If this isn't throwing any errors, perhaps you should write a catch statement in to silence the error in the final program?

Fullmouthed

This is actually with PyGObject. I ported it to PyGTK and the warning doesn't even get raised there. So that's weird... – Impale

All the same, if you get the error, and there is no actual effect on the program, you might as well mute it. If you're not getting the error, then I guess we'll never know where it came from...:3 – Fullmouthed

In regards to your final question, unfortunately, catching the warnings as exceptions isn't possible since this is in a thread and using the warnings context_manager isn't thread safe. This is a desktop application so the user wouldn't see it if they launch it from an icon, but it annoys me while developing it. – Impale

Just for clarification: at the moment I'm maintaining two forks of it, one GTK3/pygobject, one GTK2/pygtk (since there's no sane way to support both at the same time). This problem continues in the pygobject fork but, like I said, since it's not a showstopper, it's more of an annoyance to me than anything. The end-user (probably) won't see or otherwise notice it. – Impale

Answer 2

The problem is in Gtk.py's TreeModel._convert_value. It checks to see whether it can put the value in a GObject.Value(), but it initialises the Value with the type before checking whether it's suitable.

I was able to work around the problem by changing the type passed to gtk.TreeStore() from Gdk.Pixbuf to gobject.TYPE_PYOBJECT.

Home

Answer 3

In many cases, this means another thread attempted to access UI thread components.

Semiweekly