GNOME Bugzilla – Bug 692451
Anjuta crash when 'Refresh' after external file change
Last modified: 2013-02-25 14:10:19 UTC
It took me a while to detect the mechanism behind this, but I'm fairly certain this is it: - When modifying a project file externally (eg. using an editor, or glade2), Anjuta displays the 'orange' bar warning about the change, and offering to refresh the editor file. - Infrequently, this causes Anjuta to crash, without saving the session, so this caused quite a bit of reconfiguring each time. The irregularity of the problem (say once each 10 times or so) had me confused, but I'm quite certain this happens if an auto-save occurs while the file has not been 'refreshed'. I have been working without UPS for some days and had set the auto-save to 3 minutes. The crashes happened more frequently... Back on UPS, I'll switch off the auto-save if it goes away. John
Thanks for reporting this. > - Infrequently, this causes Anjuta to crash, without saving the session, so > this caused quite a bit of reconfiguring each time. The configuration is saved only when a session is closed (when you quit Anjuta or close the project). I'm agree that's it's quite annoying when you get a crash in Anjuta. I'm thinking that perhaps it would be nice to save them automatically from time to time or even after each change. > The irregularity of the problem (say once each 10 times or so) had me confused, > but I'm quite certain this happens if an auto-save occurs while the file has > not been 'refreshed'. I will check this. Which editor are you using? Scintilla or GtkSourceView.
> I'm thinking that perhaps it would be nice to save them automatically from time to time or even after each change. That would be very helpful. Maybe a save after 1 or 2 minutes of the last change? > I will check this. Which editor are you using? Scintilla or GtkSourceView. At the moment, GtkSourceView. I left Scintilla because of the configuration problems. I still have to test your patch, but the last weeks have been very difficult here... I've been using Anjuta without the auto-backup for some 4 hours, and have not had any crash, even with many 'refreshes'. John
> I've been using Anjuta without the auto-backup for some 4 hours, and have not had any crash, even with many 'refreshes'. Well, today I had a crash again, now with auto-save disabled. So that wasn't the cause. In fact, I just had two crashes: - the first was on the classic 'Refresh' button click - for the first time, I had a crash when clicking on 'save' in the 'save' dialog which appears when closing a tab of a modified file. This is the first time, but I rarely enter this situation, as most files have been saved before (either because I compiled the project, or because of an auto-save) John
I just forced the 'save' modified file dialog scenario again, and had another crash (see below). This crash seems to be GtkSourceview related. Seems strange to do an autodetect_language on saving a file? Program received signal SIGSEGV, Segmentation fault. sourceview_io_get_mime_type (sio=0x0) at sourceview-io.c:516 516 if (!sio->file) Backtrace:
+ Trace 231439
Well, it seems both crash types are GtkSourceView-related - maybe this bug should be directed there... Here is the gdb info for the crash on 'Refresh': Program received signal SIGSEGV, Segmentation fault. _gtk_source_buffer_source_mark_next (buffer=0x1ec0960, mark=mark@entry=0x2bd2b40, category=category@entry=0x0) at gtksourcebuffer.c:1865 1865 while (mark != g_array_index (buffer->priv->source_marks, GtkSourceMark *, idx)) Backtrace:
+ Trace 231441
I have tried with GtkSourceView but I haven't get any crash by using refresh. I'm not sure it's linked to the automatic refresh because only modified files are saved. When you modify a file outside Anjuta, I expect that you don't change it in Anjuta too, so it shouldn't be a problem. I still get a critical warning when refreshing a file for the second time using GtkSourceView. I don't get it with Scintilla.
Can you post the warning you get on second refresh? Carl-Anton fixed a couple of problems in the GtkSourceView I/O code in master so he might also have fixed he crash because it looks like a memory corruption to me.
As I commented before - I don't think anymore it is related to the refresh per se, but could rather be related to the file saving/loading in general: > - for the first time, I had a crash when clicking on 'save' in the > 'save' dialog which appears when closing a tab of a modified file. > This is the first time, but I rarely enter this situation, as most > files have been saved before (either because I compiled the project, > or because of an auto-save) Consistently (=every time) Anjuta segfaults when I do: 1) change the contents of a file in the editor 2) Immediately try to close the tab (using the 'x' on it) 3) I get the 'want to save' dialog and click Save. --------------- (anjuta:982): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkTextBuffer' (anjuta:982): Gtk-CRITICAL **: gtk_text_buffer_set_modified: assertion `GTK_IS_TEXT_BUFFER (buffer)' failed Program received signal SIGSEGV, Segmentation fault. sourceview_io_get_mime_type (sio=0x0) at sourceview-io.c:516 516 if (!sio->file) --------------- ... which gives the impression the GtkTextBuffer was already destroyed. Note that 'manual saves' like Ctrl-S, (menu Save), or saves caused by compilation _never_ caused a crash - but then they don't close the editor.
I get the following warning: GtkSourceView-CRITICAL **: modified_changed_handler: assertion `action != NULL' failed
+ Trace 231451
Found a wrong line in the markers_reload code but that's not the origin of the problem. Still looking for the leak...
Johannes, Would the changes of Carl-Anton (and yours) justify installed the latest version for testing?
John, partially yes, but I get the same problem as Sébastian but no crash. While trying to reproduce the crash (touch filename.c three times) I lost the content of a file once so that didn't happen again. You have been warned. I still think there is some refcounting problem but didn't manage to fix it yesterday. Probably will have a look at it during the weekend.
There are quite a lot of changes in the reloading code now so that should definitily be revisted with the current master version!
Wow... In this situation (from above): > Consistently (=every time) Anjuta segfaults when I do: > > 1) change the contents of a file in the editor > 2) Immediately try to close the tab (using the 'x' on it) > 3) I get the 'want to save' dialog and click Save. I don't get the segfault anymore, but now the file is truncated to zero length! I guess this may be the situation you mentioned. Tried with two files, exactly the same result. No error messages on the console. This is not the reloading issue per se, but it is very worrying all the same. I'll try to use this version a little, to see if the reloading works normally now. That problem was somewhat erratic, so it may take some time.
Created attachment 237109 [details] [review] sourceview: move all construction of Sourceview into constructed To do this we make the reference to the SourceviewPlugin a property so that it is set when constructed() is executed. The benefit of this is that now is the plugin variable already set when the Sourceview instance is passed to sourceview_io_new().
Created attachment 237110 [details] [review] sourceview: keep a separate reference to AnjutaShell in SourceviewIO So that we can reference it even though the parent Sourceview may have been destroyed. This is/will be used when saving the file as a result of closing it.
Created attachment 237111 [details] [review] sourceview: only cancel open operations when closing editor We want an ongoing save operation to finish even though the sourceview has been destroyed.
Created attachment 237112 [details] [review] sourceview: add checks to SourceviewIO that the parent Sourceview is alive The only function which is expected to run after the corresponding Sourceview has been destroyed is on_save_finished()
Created attachment 237114 [details] [review] sourceview: don't take extra refs during open/save This is not needed anymore since: 1) Open operations is cancelled when the Sourceview is destroyed. 2) Save operations handles the case when the Sourceview is destroyed.
Review of attachment 237109 [details] [review]: Definitly cleaner than before! Thanks!
Review of attachment 237110 [details] [review]: Not sure about the cast but otherwise looks fine - thanks! ::: plugins/sourceview/sourceview-io.c @@ +599,2 @@ sio->sv = sv; + g_object_add_weak_pointer (G_OBJECT (sv), (void**)&sio->sv); Hmm, wouldn't it be better (to read) to cast to gpointer in that case?
Review of attachment 237111 [details] [review]: Yep, makes sense to cancel only the open operation.
Review of attachment 237112 [details] [review]: IMHO it would be nicer to have a cancel object and to disconnect the callback. ::: plugins/sourceview/sourceview-io.c @@ +243,3 @@ +/* + * This function may be called after the corresponding Sourceview (sio->sv) + * has been destroyed. Shouldn't we keep a cancel object in the SourceviewIO to avoid the possibility that this is even called? @@ +441,3 @@ + if (sio->sv == NULL) + { + g_warning ("Sourceview was destroyed without canceling SourceviewIO open operation"); Doesn't seem to be an error for me as we would expect this to be called in the current code under certain conditions.
Review of attachment 237114 [details] [review]: Makes sense - dead code is good code ;)
(In reply to comment #23) > Review of attachment 237112 [details] [review]: > > IMHO it would be nicer to have a cancel object and to disconnect the callback. Do you mean a GCancellable? The reason I'm not doing that is that we want the save operation to finish even though the Sourceview has been destroyed. E.g. this is used when one pushes "save" in the close document dialog. > ::: plugins/sourceview/sourceview-io.c > @@ +243,3 @@ > +/* > + * This function may be called after the corresponding Sourceview (sio->sv) > + * has been destroyed. > > Shouldn't we keep a cancel object in the SourceviewIO to avoid the possibility > that this is even called? > > @@ +441,3 @@ > + if (sio->sv == NULL) > + { > + g_warning ("Sourceview was destroyed without canceling > SourceviewIO open operation"); > > Doesn't seem to be an error for me as we would expect this to be called in the > current code under certain conditions. This won't be called since the Sourceview calls sourceview_io_cancel_open() when it's destroyed. Perhaps we should remove the sourceview_io_cancel_open() function and have SourceviewIO cancel it by itself when the Sourceview is destroyed? Using a weak ref to get notified when that happens.
Created attachment 237237 [details] [review] sourceview: keep a separate reference to AnjutaShell in SourceviewIO So that we can reference it even though the parent Sourceview may have been destroyed. This is/will be used when saving the file as a result of closing it.
Review of attachment 237237 [details] [review]: OK, thanks!
> This won't be called since the Sourceview calls sourceview_io_cancel_open() > when it's destroyed. > Perhaps we should remove the sourceview_io_cancel_open() function and have > SourceviewIO cancel it by itself when the Sourceview is destroyed? Using a weak > ref to get notified when that happens. A weak reference sounds good to me.
Created attachment 237300 [details] [review] sourceview: only cancel open operations when closing editor We want an ongoing save operation to finish even though the sourceview has been finalized. Also rework the code so that SourceviewIO cancels the open operations by itself when the Sourceview is finalized instead of having the Sourceview be responsible for it.
Review of attachment 237300 [details] [review]: Looks good - thanks! Please commit all the patches and close the bug.
(In reply to comment #30) > Review of attachment 237300 [details] [review]: > > Looks good - thanks! > > Please commit all the patches and close the bug. I've commited the patches but I don't seem to have the permissions to mark the patches as commited or close the bug.
You should have the permissions now (at least for anjuta and gdl).