Hi all,
I have several gtk+3 apps that are all suffering from what appears to be
the same bug -- at seemingly random times, and often when a program is
quiescent (i.e., no user activity of any kind), I see the message
(myapp:13754): Gtk-CRITICAL **: gtk_tree_model_filter_get_path: assertion
'GTK_TREE_MODEL_FILTER (model)->priv->stamp == iter->stamp' failed
and the program dumps core shortly thereafter. I have included a sample
stack backtrace at the end of this message. I am currently running the
latest, or at least extremely recent, releases of all pertinent packages
(e.g., gtk+ 3.10.5, glib 2.38.2) on 64-bit CentOS 6.5 machines. The
problem has persisted over the last year across various releases of
gtk+3/glib. This bug is not directly reproducible in any program, i.e.,
there is no known exact sequence of user actions that is guaranteed to
trigger it, although one pattern of activity is under greater suspicion
than others. (See further below.)
I've researched the above error message but not found much that would seem
to apply to me. Supposedly this happens when one uses an iterator that is
not matched to one's data type or some such -- not having much clue as to
what this means, I'm certainly not doing it explicitly. I also see posts
about this from people who are using GtkTree... objects, but I am not
using any such objects directly, although it's possible that the gtk+
objects I *am* using are built from GtkTree... components.
Because this is happening in multiple applications, I think it unlikely
that I have a single coding error that is stepping on gtk+3 data
structures. It seems more likely that (1) I am using some gtk+3 object in
a way which is not safe, or (2) there's simply a bug in gtk+3 and friends.
I'm pursuing #1 at the moment, although there's certainly no shortage of
reports of this problem in various bits of software around the web.
I have three particular questions about this:
(1) If I have any suspicions about my own gtk+3 usage, they are centered
on file chooser dialogs. The beginnings of this problem roughly correlate
with a time when I replaced code that required typing filenames into a
text entry field by code that popped up a file chooser dialog to aid in
filling that field. File chooser dialogs are obviously composite widgets
including a list structure that may well be built from one or more
instances of GtkTree... elements somehow. (Can anyone confirm or deny?)
The documentation examples generally show such dialogs being created, run,
and immediately destroyed. Trying to be thrifty, my code creates a single
file chooser dialog at program start time, then runs that same dialog
repeatedly as necessary without ever destroying it, rather than going
through the same create->run->destroy cycle every time I need to prompt
for a filename. Is there a problem with my approach? Is there anything I
need to do to anesthetize a dialog when I'm not using it so that it's not
doing some useless and dangerous background tree traversal or something
when it shouldn't? These errors pretty much never occur when I'm actively
using a dialog (either displaying it or dismissing it) but rather when
there's nothing particularly interesting going on after some significant
amount of time has passed since dismissing the dialog.
(2) If my file chooser dialog usage as described above is not problematic,
can anyone tell me what other commonly used gtk+3 widgets are implemented
using GtkTree... components and may be the cause of these errors? My GUIs
are generally drawing areas embedded within a scrolled window, using popup
menus, dialogs and other dialog-like windows which contain customized
arrangements of various text, radiobutton, etc., items arranged within a
layout. (All of my dialog and dialog-like windows are objects that, like
my file chooser dialogs, are permanent, i.e., created only once at program
startup time, then shown and hidden repeatedly as needed depending upon
user activity.) I'm using cairo for all of my imaging into the drawing
areas but do not suspect any cairo involvement in this mess as I do not
use it to overdraw anything other than drawing area surfaces.
(3) Finally, can anyone recommend a way to debug this? As I have said,
there is no way to reliably trigger the bug. Last Friday I banged on the
program for an entire day, making heavy use of file chooser dialogs, and
all was fine. Monday morning I came into the office to find that the bug
crashed my program over the weekend when there had been absolutely zero
user interaction with the entire window system for a period of over 12
hours. I'm thinking the only useful thing I could do would be to fill up
the gtk3/glib library code with printf statements, but I really don't know
what areas of these libraries to target. What I need to do first is
discover which of my gtk+ objects is responsible for initiating the call
sequence that results in the assertion failure.
