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.
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?