Re: Interesting problem with GtkTreeView

[Tim Müller <zen18864 zen co uk>]

On Friday 05 December 2003 16:53, Dimitar Haralanov wrote:


> >     I am working on a piece of code which makes use of a
> > GtkTreeModel/GtkListStore which is displayed in a few GtkTreeViews.
> >     The problem that I am running into is the following: when I have
> >     only
> > one of the GtkTreeViews open, I can successfully remove any/all items
> > from the GtkTreeModel. However, when I have two of the TreeViews open,
> > I can only remove items that are not in the first row. When I try
> > removing the iterm in the first row, my app crashes with the following
> > error:
> >
> > (gkrellm:3729): Gtk-CRITICAL **: file ../../gtk/gtkliststore.c: line
> > 566(gtk_list_store_get_value): assertion `GTK_LIST_STORE
> > (tree_model)->stamp == iter->stamp' failed
> >
> > (gkrellm:3729): GLib-GObject-WARNING **: gtype.c:2967: type id `0' is
> > invalid
> >
> > (gkrellm:3729): GLib-GObject-WARNING **: can't peek value table for
> > type`<invalid>' which is not currently referenced Segmentation fault
> > (core dumped)
> >
> >     Has anyone battled/seen this that could give me a hint of where
> >     I am going wrong?
>
>       I still have not been able to figure anything out here and the list's
> silences leads me to the idea that no one has actually seen this
> problem?
>       One of the problem that I am facing while trying to debug this is that
> I can get any debugging information for the gtk functions. Does anyone
> know whether there is anything that I can do to get meaningful gtk
> backtraces without having to recompile GTK+, GLib, etc with debugging
> enabled?

Aren't there -dbg packages for your distro which get installed into /usr/lib/
debug, so that you just have to do export LD_LIBRARY_PATH=/usr/lib/debug in 
bash before running your program? (libgtk2.0-dbg on debian)

I've seen similar errors twice so far, and both gdb and valgrind were utterly 
useless finding the problem (you did run your program through valgrind, 
didn't you?) If I got a stack trace at all, it would always indicate some 
gtk/glib functions somewhere, surrounded by plenty of '???'.  Both times the 
problem turned out to be a bug in my code where I returned inconsistent 
information from custom sort functions - that would make the sort algorithms 
smash the stack badly (because it accessed array[n] where n<0 due to the 
inconsistent return values of my compare function). I'd be surprised if that 
was the cause for your problems as well, but it's at least something to 
check ;-)

Have you tried isolating the problem by putting together a small stand-alone 
test case?

Cheers
-Tim