GNOME Bugzilla – Bug 605881
Crash when hitting enter key or deleting lines of code in Anjuta
Last modified: 2010-02-28 19:50:07 UTC
Every so often, when I either create a new line by hitting the Enter key, or when I delete a line of code in Anjuta, it crashes in GtkSourceView: Program received signal SIGSEGV, Segmentation fault. 0x0279ac2d in idle_scan_regions (buffer=0x996ec10) at gtksourcecompletionwordsbuffer.c:287 287 remove_line ((GList *)ptr->data, buffer); (gdb) bt
+ Trace 219854
Just to be sure, you are using the latest 'master' of gtksourceview. There have been some changes recently concerning this kind of bug (see 2e5428c0).
I have experienced the same but I didn't check with the latest trunk version. Anyway, a work-around in anjuta for now is to disabled autocompletion of words in the sourceview preferences (language assistance will still work).
(In reply to comment #1) > Just to be sure, you are using the latest 'master' of gtksourceview. There have > been some changes recently concerning this kind of bug (see 2e5428c0). Pulled from git and recompiled today; it crashed as I was typing.
I can't easily reproduce this with gedit or test-completion in the gtksourceview repository. Are there any settings for the word-completion provider that are not the default? Or anything in the use of GtkSourceCompletion in Anjuta that might trigger this bug in the word completion provider?
I just compiled anjuta 2.29.4 but also can't seem to be able to reproduce. Is there an easy way of triggering this, or does it just occasionally happen?
Well, the only way I caught the backtrace I got was to run anjuta under gdb, and then just hack like usual until it crashed. Sorry I can't come up with a better recipie :(
James: does this still happen?
Happened with me as well. And when I filed a new bug, I came across this one :). It's with "master". Here is a patch as well. The bug: in Anjuta, where word completion is enabled, gtksouceview crashes when pressing enter in last line of document. There happens a NULL pointer dereference at gtksourcecompletionwordsbuffer.c:287. (gdb) run Starting program: /usr/local/bin/anjuta [Thread debugging using libthread_db enabled] [New Thread 0xb7820b70 (LWP 3376)] [New Thread 0xb701eb70 (LWP 3379)] [New Thread 0xb5ac7b70 (LWP 3408)] [New Thread 0xb5028b70 (LWP 3413)] [Thread 0xb5028b70 (LWP 3413) exited] [Thread 0xb7820b70 (LWP 3376) exited] [New Thread 0xb7820b70 (LWP 3416)] [New Thread 0xb5028b70 (LWP 3424)] [New Thread 0xb46ffb70 (LWP 3425)] [New Thread 0xb3efeb70 (LWP 3426)] [Thread 0xb7820b70 (LWP 3416) exited] [Thread 0xb3efeb70 (LWP 3426) exited] [Thread 0xb5028b70 (LWP 3424) exited] [New Thread 0xb5028b70 (LWP 3440)] [New Thread 0xb3efeb70 (LWP 3441)] [New Thread 0xb7820b70 (LWP 3442)] [Thread 0xb3efeb70 (LWP 3441) exited] [Thread 0xb7820b70 (LWP 3442) exited] [Thread 0xb46ffb70 (LWP 3425) exited] [New Thread 0xb46ffb70 (LWP 3445)] [New Thread 0xb7820b70 (LWP 3446)] [New Thread 0xb3efeb70 (LWP 3447)] [Thread 0xb7820b70 (LWP 3446) exited] [Thread 0xb46ffb70 (LWP 3445) exited] [Thread 0xb3efeb70 (LWP 3447) exited] [Thread 0xb5028b70 (LWP 3440) exited] Program received signal SIGSEGV, Segmentation fault. 0x03db63ad in idle_scan_regions (buffer=0x8fefb88) at gtksourcecompletionwordsbuffer.c:287 287 remove_line ((GList *)ptr->data, buffer); (gdb) bt
+ Trace 220615
282 ptr = g_list_nth (ptr, region->start - prev); 283 284 for (i = 0; i < doscan; ++i) 285 { 286 /* First remove this line */ 287 remove_line ((GList *)ptr->data, buffer); 288 289 /* Then scan it which adds words */ 290 ptr->data = scan_line (buffer, region->start + i); 291 (gdb) print ptr $1 = (GList *) 0x0 (gdb) print *region $4 = {start = 535, end = 535} (gdb) print g_list_length (buffer->priv->lines) $7 = 535 (gdb) print i $8 = 0 At a glance, the reason seems to be that the scan loop goes beyond document boundary. I am not sure if the loop is supposed to be somehow aligned with document end, but it doesn't seem to. Here is a patch that breaks the loop when reaching the boundary in any case.
Created attachment 154077 [details] [review] Put a boundary check for document end.
The patch fixes the problem, but as you said, the scanning should be aligned with the end of the document. This probably means that the region stack is corrupt at the time of the crash.
How could the region stack be currupt? General memory corruption of something wrong in GtkTextView/GtkSourceView? I would really apreciate if this patch could be applied because otherwise I guess we would have to disable the "Word" provider entirely in anjuta because it's just crashing far too often.
The problem is definitely in the words completion. It should keep the stack of scan regions in sync with the changes in the buffer. The rest of the code (in particular where the crash happens) assumes it can trust the scan regions to be valid. What I mean was that the crash indicates that there is a problem in keeping the scan regions correct. Fixing it like with the patch is not correct because the scan regions will still be wrong (and might break other places). I will have a look at the problem today. If I can't find the problem in time, we can still apply this patch as a temporary measure to at least not have it crash. But I want to find the real cause.
*** Bug 611201 has been marked as a duplicate of this bug. ***
Created attachment 154904 [details] [review] Word completion crasher fix This patch should fix the issues with the word completion. Basicly changed the whole approach because the previous one was not going to work with the way insert-text/delete-range works. The proposed patch uses marks instead to mark regions in the buffer that need to be scanned. It keeps the doc in sync with the library by scanning words also when they need to be removed, and keeping a hash table to the proposals.
I went ahead and committed the patch, together with some small improvements to the performance hit when you load large documents.