GNOME Bugzilla – Bug 610394
crash: During autocompletion
Last modified: 2010-08-13 14:11:41 UTC
I was just typing something, autocomplete window came up and it crashed. Before the crash, the autocomplete window really changed a lot while typing. (gdb) bt
+ Trace 220630
Some messages before it crashed: (anjuta:16874): GLib-CRITICAL **: g_list_insert_before: assertion `sibling == list' failed (anjuta:16874): Gtk-CRITICAL **: gtk_tree_row_reference_new: assertion `path != NULL' failed (anjuta:16874): Gtk-CRITICAL **: gtk_tree_model_row_inserted: assertion `path != NULL' failed (anjuta:16874): Gtk-CRITICAL **: gtk_tree_path_next: assertion `path != NULL' failed Program received signal SIGSEGV, Segmentation fault.
From the stacktrace I would say this is a problem in gtksourceview. Do you have master of gtksourceview installed?
(In reply to comment #1) > From the stacktrace I would say this is a problem in gtksourceview. Do you have > master of gtksourceview installed? Yes, I do. Fresh as it can be. Please see bug 605881 also, it may be related (although crash points are different). That bug has a possible patch from me that prevents the crash, so it would be nice if you can convince sourceview guys to evaluate it for next release. It's is also one of the top happenings in "crash while editting".
Actually, I don't think this bug is relatd to bug 605881. Bug 605881 no longer happens to me after the patch there, but this one still happens.
I'm not getting this here, I'm usually use scintilla. Anyway, do you remember what you were writing when it crashed?
I checked today and there seems to be some memory corruption somewhere. Have to check with valgrind tommorow. Could also be a problem in gtksourceview but I doesn't look like that. I got various different traces as it crashed far too often.
(In reply to comment #4) > I'm not getting this here, I'm usually use scintilla. > Anyway, do you remember what you were writing when it crashed? I was mostly writing some function names or variable names. It triggers autocomplete and a bunch of assert failures in autocomplete tree model (like model is invalid etc. etc.) followed by a crash.
Please recheck with master. The code was completely rewritten.
I have used it for a day or so and the crash does not happen. Thanks a lot! However, couple new things. One is that I get freezes when typing when autocomplete appears. I often manage to type 5 to 10 chars before the autocomplete window is rendered. The other thing is that I get following (harmless) warnings: (anjuta:14312): libanjuta-symbol-db-DEBUG: symbol-db-search-command.c:192 (sdb_search_command_run) Notify! (anjuta:14312): libanjuta-symbol-db-DEBUG: symbol-db-search-command.c:192 (sdb_search_command_run) Notify! (anjuta:14312): libanjuta-symbol-db-DEBUG: symbol-db-search-command.c:169 (sdb_search_command_run) Searching async with type 0 (anjuta:14312): libanjuta-symbol-db-DEBUG: symbol-db-search-command.c:169 (sdb_search_command_run) Searching async with type 1 (anjuta:14312): libanjuta-symbol-db-DEBUG: symbol-db-search-command.c:169 (sdb_search_command_run) Searching async with type 2 (anjuta:14312): libanjuta-symbol-db-DEBUG: symbol-db-search-command.c:185 (sdb_search_command_run) Async search returned no results (anjuta:14312): libanjuta-symbol-db-DEBUG: symbol-db-search-command.c:192 (sdb_search_command_run) Notify! (anjuta:14312): libanjuta-symbol-db-DEBUG: symbol-db-search-command.c:192 (sdb_search_command_run) Notify! (anjuta:14312): GtkSourceView-CRITICAL **: _gtk_source_completion_add_proposals: assertion `item != NULL' failed (anjuta:14312): GtkSourceView-CRITICAL **: _gtk_source_completion_add_proposals: assertion `item != NULL' failed Also, as a sidenote, I think we should introduce a timeout between char-added and autocomplte search (something like 200ms). Usually, we stop and ponder a little bit if we need help from autocomplete, other type ahead really fast because we know what to type.
(In reply to comment #8) > I often manage to type 5 to 10 chars before the > autocomplete window is rendered. > I mean ... before editor unfreezes to display the chars.
Hi! > (anjuta:14312): GtkSourceView-CRITICAL **: > _gtk_source_completion_add_proposals: assertion `item != NULL' failed > > (anjuta:14312): GtkSourceView-CRITICAL **: > _gtk_source_completion_add_proposals: assertion `item != NULL' failed Hmm, haven't seen those yet but that really shouldn't happen. Could you maybe get a stacktrace with --g-fatal-warnings? > Also, as a sidenote, I think we should introduce a timeout between char-added > and autocomplte search (something like 200ms). Usually, we stop and ponder a > little bit if we need help from autocomplete, other type ahead really fast > because we know what to type. This timeout is already implemented in gtksourceview. You will notice that no completion appears when you type fast. This typeout could even be configured using the "auto-complete-delay"-property (http://library.gnome.org/devel/gtksourceview/unstable/GtkSourceCompletion.html#GtkSourceCompletion--auto-complete-delay). However, it's difficult to calculate this correctly for any PC. I agree though that performance could sometimes be improved. I found it quite usable on my netbook though.
(In reply to comment #10) > > Hmm, haven't seen those yet but that really shouldn't happen. Could you maybe > get a stacktrace with --g-fatal-warnings? > (gdb) bt
+ Trace 220850
> > Also, as a sidenote, I think we should introduce a timeout between char-added > > and autocomplte search (something like 200ms). Usually, we stop and ponder a > > little bit if we need help from autocomplete, other type ahead really fast > > because we know what to type. > > This timeout is already implemented in gtksourceview. You will notice that no > completion appears when you type fast. > I guess that takes care of showing the results, but I think the async searches are still triggered, sometimes multiple of them (overlapping/stacking searches since they are not truly canceled at backend). > I agree though that performance could sometimes be improved. I found it quite > usable on my netbook though. I am running anjuta in vmware with full debugging prints and -O0, on x301 laptop. It's pretty slow :). But gedit and other editors works fine. I guess anjuta works smoothly in a faster machines, but this configuration is not really out of the world either.
Reopening as the stacktrace has been provided.
*** This bug has been marked as a duplicate of bug 625465 ***