Gtk-CRITICAL assertion failed (file dialogs?)

[Roger Davis <rbd soest hawaii edu>]

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.

Any suggestions on how to fix this incredibly frustrating problem would be 
most gratefully welcomed!

Roger Davis
Univ. of Hawaii

PS: Stack backtrace follows. This is typical, although not always the 
same, for this problem. There is pretty much always a call to some kind of 
gtk_tree_*_row_deleted() function somewhere on the stack. Here it is:

#0  0x00007f07545c1a0b in find_root (seq=0x2201480) at gsequence.c:1570

#1  node_get_length (seq=0x2201480) at gsequence.c:1791

#2  g_sequence_get_length (seq=0x2201480) at gsequence.c:1256

#3  0x00007f0756130d73 in gtk_tree_model_filter_row_deleted 
(c_model=<value optimized out>, c_path=0x2201480, data=0x7f07340034b0) at 
gtktreemodelfilter.c:2592

#4  0x00007f075489bdc2 in g_closure_invoke (closure=0x237ee60, 
return_value=0x0, n_param_values=2, param_values=0x7fffb5a1eca0, 
invocation_hint=<value optimized out>) at gclosure.c:777

#5  0x00007f07548b2341 in signal_emit_unlocked_R (node=<value optimized 
out>, detail=0, instance=0x22b4d80, emission_return=0x0, 
instance_and_params=0x7fffb5a1eca0) at gsignal.c:3586

#6  0x00007f07548b38df in g_signal_emit_valist (instance=<value optimized 
out>, signal_id=<value optimized out>, detail=0, var_args=<value optimized 
out>) at gsignal.c:3330

#7  0x00007f07548b3ce3 in g_signal_emit (instance=<value optimized out>, 
signal_id=<value optimized out>, detail=<value optimized out>) at 
gsignal.c:3386

#8  0x00007f0755fe1c6d in emit_row_deleted_for_row (model=0x22b4d80, 
row=<value optimized out>) at gtkfilesystemmodel.c:331

#9  0x00007f0755fe3df5 in remove_file (monitor=<value optimized out>, 
file=<value optimized out>, other_file=<value optimized out>, type=<value 
optimized out>, model=0x22b4d80) at gtkfilesystemmodel.c:1912

#10 gtk_file_system_model_monitor_change (monitor=<value optimized out>, 
file=<value optimized out>, other_file=<value optimized out>, type=<value 
optimized out>, model=0x22b4d80) at gtkfilesystemmodel.c:1257

#11 0x00007f0752d7d45c in ffi_call_unix64 () at ../src/x86/unix64.S:75

#12 0x00007f0752d7cbf3 in ffi_call (cif=<value optimized out>, 
fn=0x7f0755fe3bf0 <gtk_file_system_model_monitor_change>, rvalue=<value 
optimized out>, avalue=0x7fffb5a1f1b0) at ../src/x86/ffi64.c:492

#13 0x00007f0754899d48 in g_cclosure_marshal_generic_va 
(closure=0x23393d0, return_value=0x0, instance=0x2355a00, args_list=<value 
optimized out>, marshal_data=0x7f0755fe3bf0, n_params=3, 
param_types=0xcc5f70) at gclosure.c:1550

#14 0x00007f075489bc0a in _g_closure_invoke_va (closure=0x23393d0, 
return_value=0x0, instance=0x2355a00, args=0x7fffb5a1f610, n_params=3, 
param_types=<value optimized out>) at gclosure.c:840

#15 0x00007f07548b2f2d in g_signal_emit_valist (instance=<value optimized 
out>, signal_id=<value optimized out>, detail=0, var_args=<value optimized 
out>) at gsignal.c:3238

#16 0x00007f07548b3ce3 in g_signal_emit (instance=<value optimized out>, 
signal_id=<value optimized out>, detail=<value optimized out>) at 
gsignal.c:3386

#17 0x00007f07556b15d1 in emit_cb (data=0x2355a00) at gfilemonitor.c:392

#18 0x00007f07545a9593 in g_main_dispatch (context=0x9e14c0) at 
gmain.c:3066

#19 g_main_context_dispatch (context=0x9e14c0) at gmain.c:3642

#20 0x00007f07545ab5f8 in g_main_context_iterate (context=0x9e14c0, 
block=1, dispatch=1, self=<value optimized out>) at gmain.c:3713

#21 0x00007f07545ac625 in g_main_loop_run (loop=0x20107a0) at gmain.c:3907