Re: gtkrbtree core dump
Hello Emmanuele, Thank you for your suggestions! the RBTree is a private data structure used internally by gtk+. Some people here have suggested that this rbtree code is used by GtkTreeView objects, so I have been focusing my attention on parts of my code which might be referencing such things indirectly. I do not use any GtkTreeView objects directly in my code. Are you saying that this rbtree code is also used by other parts of GTK that have nothing to do with GtkTreeView objects? use gdb and gather a stack trace of the assertion failure. you'll see the call stack, so you'll be able to figure out what's calling that function with a empty RBTree. I am hoping to do this, unfortunately these failures are pretty rare and I cannot cause one on demand. My reading of the code, however, indicates that the g_assert fails because tree-root is *not* nil: g_assert (_gtk_rbtree_is_nil (tree->root)); I am trying to understand what happens inside g_assert. The glib documentation says it should dump core inside the assert *unless* the g_assert macro has been turned off, and then implies that the macro is probably turned off in a final code release, which should mean that the core dump is actually happening later on, perhaps in a very different stack backtrace. Do you know anything about this? Is there a way I can examine the code build configuration to determine whether the assert core dump is enabled or disabled? I suppose that ideally I would like the core dump to occur in the assertion so I can better locate the source of the failure. Thanks! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkrbtree core dump
On 30 September 2012 17:37, Roger Davis wrote: > > Hello all, > > I am encountering an infrequent but serious bug which is causing core dumps > in one or more of my GTK3+ apps. At the time my code dumps core I see the > message > > Gtk:ERROR:gtkrbtree.c:465:_gtk_rbtree_insert_after: assertion failed: > (_gtk_rbtree_is_nil (tree->root)) the RBTree is a private data structure used internally by gtk+. use gdb and gather a stack trace of the assertion failure. you'll see the call stack, so you'll be able to figure out what's calling that function with a empty RBTree. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkrbtree core dump
There are much more to explore. The most effective way I found to approach this kind of issues is grepping inside the source tree: $ grep -rl gtk_tree_view *.c gtkappchooserwidget.c ... Thanks for the suggestion, Nicola. After looking at gtkfilechooserdefault.c a bit, I guess I would interpret that code as showing that while a file chooser dialog is not a descendant of a GtkTreeView, it uses some private internal data strutures which are in fact GtkTreeView (or related) objects. I guess the same would apply to other object types which make some private use of a hidden GtkTreeView object while not being directly related themselves to GtkTreeView. Thanks! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkrbtree core dump
Hi Tadej, I am looking at the docs but not seeing what you are describing. IF you want to see which widgets are derived from GtkTreeView, simply open GtkTreeView API docs and check "Object Hierarchy" section. Direct descendants will be listed here (if there are any). There is no "stock" gtk widget that would be derived from GtkTreeView. The object hierarchy graph at http://developer.gnome.org/gtk3/stable/GtkTreeView.html shows only the ancestors of GtkTreeView: GObject +---GInitiallyUnowned +---GtkWidget +---GtkContainer +---GtkTreeView Am I looking at the wrong graph? File chooser dialogs use GtkTreeView to display files/folders and as far as I can tell from your description, this is the only place where tree view is used in your app. Maybe file system changes cause tree view to update itself in a bad way? (I'm mostly guessing here after a quick git grep through sources.) I could believe that file chooser dialogs are somehow related to GtkTreeView, but this is not shown in the object hierarchy graph at http://developer.gnome.org/gtk3/stable/GtkFileChooserDialog.html: GObject +---GInitiallyUnowned +---GtkWidget +---GtkContainer +---GtkBin +---GtkWindow +---GtkDialog +---GtkFileChooserDialog Again, am I looking in the wrong place? Can you refer me to the GTK+3 documentation page which shows the connection between file chooser dialogs and GtkTreeView? There do seem to be a few cases in the GTK+3 documentation pages where a particular object's hierarchy graph does show at least immediate descendants as well as ancestors (e.g., GtkContainer, GtkDialog), but this does not seem to be the case in general. Thanks! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkrbtree core dump
Il Sun, 30 Sep 2012 08:48:20 -1000 (HST) Roger Davis scrisse: > I was wondering about that, but unfortunately my code does not explicitly > use any GtkTree* objects! Is there any way to search the documentation > efficiently to determine which object types are inheriting from > GtkTreeView? I have begun searching on my objects one by one (e.g., > GtkMenu, etc.), but I am not finding any that appear to inherit from > GtkTree*. Of course my app uses dozens of different object types and it > will be quite a chore to exhaustively search the documentation of each one > to examine its object hierarchy graph. I suspect that in the end I will > come up empty, as I have already looked at the objects I am using which, > by their appearance, look the most related to a GtkTreeView, e.g., menus, > file chooser dialogs, etc. There are much more to explore. The most effective way I found to approach this kind of issues is grepping inside the source tree: $ grep -rl gtk_tree_view *.c gtkappchooserwidget.c gtkcellarea.c gtkcellrendererspinner.c gtkcombobox.c gtkcustompaperunixdialog.c gtkentry.c gtkentrycompletion.c gtkfilechooserdefault.c gtkfontsel.c gtkmountoperation.c gtkprintunixdialog.c gtkrecentchooserdefault.c gtktooltip.c gtktreednd.c gtktreeselection.c gtktreeview.c gtktreeviewcolumn.c Ciao. -- Nicola ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkrbtree core dump
Hi. > I was wondering about that, but unfortunately my code does not explicitly > use any GtkTree* objects! Is there any way to search the documentation > efficiently to determine which object types are inheriting from > GtkTreeView? I have begun searching on my objects one by one (e.g., > GtkMenu, etc.), but I am not finding any that appear to inherit from > GtkTree*. Of course my app uses dozens of different object types and it > will be quite a chore to exhaustively search the documentation of each one > to examine its object hierarchy graph. I suspect that in the end I will > come up empty, as I have already looked at the objects I am using which, > by their appearance, look the most related to a GtkTreeView, e.g., menus, > file chooser dialogs, etc. IF you want to see which widgets are derived from GtkTreeView, simply open GtkTreeView API docs and check "Object Hierarchy" section. Direct descendants will be listed here (if there are any). There is no "stock" gtk widget that would be derived from GtkTreeView. File chooser dialogs use GtkTreeView to display files/folders and as far as I can tell from your description, this is the only place where tree view is used in your app. Maybe file system changes cause tree view to update itself in a bad way? (I'm mostly guessing here after a quick git grep through sources.) Cheers, Tadej -- Tadej Borovšak tadej.borov...@gmail.com tadeb...@gmail.com tadeboro.blogspot.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkrbtree core dump
Thanks, Nicola. AFAIK GtkRBTree (hence _gtk_rbtree_insert_after) is used extensively by GtkTreeView I was wondering about that, but unfortunately my code does not explicitly use any GtkTree* objects! Is there any way to search the documentation efficiently to determine which object types are inheriting from GtkTreeView? I have begun searching on my objects one by one (e.g., GtkMenu, etc.), but I am not finding any that appear to inherit from GtkTree*. Of course my app uses dozens of different object types and it will be quite a chore to exhaustively search the documentation of each one to examine its object hierarchy graph. I suspect that in the end I will come up empty, as I have already looked at the objects I am using which, by their appearance, look the most related to a GtkTreeView, e.g., menus, file chooser dialogs, etc. Thanks! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkrbtree core dump
Il Sun, 30 Sep 2012 06:37:12 -1000 (HST) Roger Davis scrisse: > Has anyone else ever seen this (I found only a couple not especially > helpful references on the web), and/or does anyone know what is calling > _gtk_rbtree_insert_after()? It isn't me, at least not directly, and I can > find no reference to it in the GTK+3 docs. What kind of programming error > on my part might lead to such an outcome? You did not (and will not) find any documentation on _gtk_rbtree_insert_after() because it is a private exported function. AFAIK GtkRBTree (hence _gtk_rbtree_insert_after) is used extensively by GtkTreeView, so I'd look at my code using it. Ciao. -- Nicola ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtkrbtree core dump
Hello all, I am encountering an infrequent but serious bug which is causing core dumps in one or more of my GTK3+ apps. At the time my code dumps core I see the message Gtk:ERROR:gtkrbtree.c:465:_gtk_rbtree_insert_after: assertion failed: (_gtk_rbtree_is_nil (tree->root)) The last time this happened a few days ago my app was actually in a quiescent state in terms of GUI events -- it just up and core dumped even though no user interactivity (and resulting callbacks) had taken place for a minute or two. There was a work procedure (registered via g_idle_add_full) being called periodically to check for external file input data, but that input was also quiescent, and in any case the work procedure makes no changes to any GTK objects. In my development and testing I see this occur once every couple of weeks, and I believe that I have seen it in multiple apps although it happens so rarely that I am not certain about that. It is impossible to duplicate. Unfortunately some of my apps are intended to run for weeks at a time, having them crash is a very bad thing, and the likelihood of this occurring at least once during such a time period is unacceptably high. Has anyone else ever seen this (I found only a couple not especially helpful references on the web), and/or does anyone know what is calling _gtk_rbtree_insert_after()? It isn't me, at least not directly, and I can find no reference to it in the GTK+3 docs. What kind of programming error on my part might lead to such an outcome? Thanks! Roger Davis Univ. of Hawaii ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
