bugGNU Octave - Bugs: bug #62271, GUI crashes and clears function...

 
 

bug #62271: GUI crashes and clears function files on closing

Submitter:  None
Submitted:  Fri 08 Apr 2022 05:33:48 PM UTC
 
Category:  GUI Severity:  4 - Important
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Andrea Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 7.1.0
Operating System:  * Any
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Tue 05 Jul 2022 03:35:01 PM UTC, comment #32: 

patch was pushed on stable, so should be part of 7.2.0. I haven't heard any followup issues since May, so yes, I'd think this can be closed.

Nicholas Jankowski <nrjank>
Project Member
Tue 05 Jul 2022 03:07:16 PM UTC, comment #31: 

No further reports since May.  Okay to close report as Fixed?

Rik <rik5>
Project Administrator
Mon 23 May 2022 08:11:43 PM UTC, comment #30: 

Updating title since this bug is not restricted to Windows.

Torsten Lilge <ttl>
Project Member
Sun 22 May 2022 06:04:28 PM UTC, comment #29: 

As Markus commented in bug #62508, the fix from comment #28 is included in the nightly builds that are available at https://buildbot.octave.space/#/download

With these nightly builds, you can re-enable removing trailing spaces when saving a file.

Torsten Lilge <ttl>
Project Member
Mon 16 May 2022 09:14:52 PM UTC, comment #28: 

I have pushed cset http://hg.savannah.gnu.org/hgweb/octave/rev/2b4f7287aa3a

The patch fixes removing trailing spaces when saving a modified file that is being closed, which was the cause of the crash/hang. And it avoids emptying the file if still something goes wring between opening the file and saving the contents.

For testing, here the steps to reproduce the bug (without patch);

  1. Enable removing trailing spaces in the settings
  2. Modify a file and add trailing spaces and leave the file modified
  3. Close octave and click "Save" in the dialog related to the modified file
  4. Instead of saving the file and just exiting, Octave remains busy and the file on the disk is empty

With the changeset above, the behavior should be as expected.

Torsten Lilge <ttl>
Project Member
Mon 16 May 2022 09:31:48 AM UTC, comment #27: 

comment #23:

> @sigi_s: does the crash/hang occurs every time you are trying to save a file while octave is closing?

no.

Siegbert Steinlechner <sigi_s>
Mon 16 May 2022 04:54:41 AM UTC, comment #26: 

It's the other way around: The save routine triggers removing the trailing spaces before actually saving.

Torsten Lilge <ttl>
Project Member
Sun 15 May 2022 10:57:08 PM UTC, comment #25: 

Does this setting default to On in 7.1.0? 

I haven't been able to test it, but for consideration, I assume the trailing blank removal triggers a Save routine? is it using the Qfile or QSaveFile routine for that?

Nicholas Jankowski <nrjank>
Project Member
Sun 15 May 2022 08:37:28 PM UTC, comment #24: 

I was able to reproduce the issue on Debian/Gnome. It looks like the routine which replaces the trailing spaces hangs in an endless loop. From my testing so far, the issue only seems to occur when the removal of trailing spaces is activated in the preferences and if the file actually has trailing spaces.

I am currently trying to find the specific cause in the replace routine.

For now, please disable the preference "Remove trailing spaces when saving file" in the editor tab of the preferences dialog.

Torsten Lilge <ttl>
Project Member
Sun 15 May 2022 07:14:32 PM UTC, comment #23: 

@sigi_s: does the crash/hang occurs every time you are trying to save a file while octave is closing?

Torsten Lilge <ttl>
Project Member
Sun 15 May 2022 07:10:36 PM UTC, comment #22: 

There is a new bug #62467 that reports the same issue:

Using Octave 7.1.0 I had now 2 times the problem, that Octave asked me to save my actual m file when I tried to end my Octave session. I answered yes, then Octave hanged and had to be stopped using the task manager. Then my m-File (containing 2 days of work) was destroyed - it was completely empty. Fortunately I could recover the file content using a disk editor.

The discussion continues here, as bug #62467 is closed as dupicate.

Torsten Lilge <ttl>
Project Member
Thu 05 May 2022 04:50:47 PM UTC, comment #21: 

If there was a problem with write permissions, there should have been a warning dialog. And the windows update was already finished (except for the restart), so no heavy hard disk or other actions in the background.

Torsten Lilge <ttl>
Project Member
Thu 05 May 2022 07:44:26 AM UTC, comment #20: 

@nrjank, "was the crash immediate after you saw the file name tab update?"

Yes.

Then the GUI freeze, maybe not crashed, I've waited a few minutes and eventually killed it manually.

Just octave freezes.

It was not the 1st save, the file was not empty AFAICJ. Of course my administrator or something could have mess up my read/write access privilege, or bad sector on the disk ; but I doubt.

> getenv('temp')

was '.../appdata/local/temp/' there is indeed some octave files there, but I could no found mine (though it could be hard to find)

sylvain bougnoux <sbougnoux>
Thu 05 May 2022 07:19:56 AM UTC, comment #19: 

> @Sylvain: Do you have the editor preferences "Remove trailing spaces..." and "Force newline..." when saving files checked?


Yes both, I guess it is the default

>@Sylvain, you wrote that windows was updating while you tried to save the file.


Windows made some updates a few minutes/hours before, I am not sure it was doing it; but at least was waiting for a pending reboot.

sylvain bougnoux <sbougnoux>
Wed 04 May 2022 05:45:31 PM UTC, comment #18: 

@Sylvain, you wrote that windows was updating while you tried to save the file.
@Andrea: Was your system also busy when the crashs happened?

Torsten Lilge <ttl>
Project Member
Mon 02 May 2022 06:44:28 PM UTC, comment #17: 

Yes, the new patch should prevent situations like the one described here. But: Why does this happen that often in 7.1 and never(?) before? I do not see any obvious changes around file saving that explains this.

Torsten Lilge <ttl>
Project Member
Mon 02 May 2022 06:27:49 PM UTC, comment #16: 

Reply to comment #13: As far as I can see after a first look, there is nothing directly related to saving files that has changed recently. Here the actions after the file is written, flushed and closed:

  • Re-add file to the file system watcher (detect external changes)
  • Update lexer
  • Update tab title
  • Close tab if this was desired

The last changes around the saving action were in May 2020 (well before 6.1) and related to trailing spaces and new line at end fo file.

@Sylvain: Do you have the editor preferences "Remove trailing spaces..." and "Force newline..." when saving files checked?

Torsten Lilge <ttl>
Project Member
Mon 02 May 2022 06:26:50 PM UTC, comment #15: 

oh, i thought that merge was before the 7.1 release. my mistake.  in that case does it just seem we just seeing a case of the error that patch should avoid in the future?

Nicholas Jankowski <nrjank>
Project Member
Mon 02 May 2022 05:47:27 PM UTC, comment #14: 

Reply to comment #9: The cahngeset was done in the default branch, since it was too close before the new release for stable. Since it was after merging default into stable for 7.1 the new save method is not included in 7.1 and can not cause the issues we are seeing here.

Torsten Lilge <ttl>
Project Member
Mon 02 May 2022 05:02:48 PM UTC, comment #13: 

(sorry for the string of comments)

@ttl - what else happens immediately after a save?

- it checks for a file name / tap update
- i believe it also reloads the file to make sure line numbers, breakpoints, function definitions, are refreshed in the interpreter, correct?
- anything else? can we imagine how any of those might result in an overwritten, now-empty, file? or a file access error that would corrupt the file and make it revert to a zero byte file?

Nicholas Jankowski <nrjank>
Project Member
Mon 02 May 2022 04:59:17 PM UTC, comment #12: 

another clarification:

in the series of events you described:

(press ctlr+S, file name tab updated by GUI, GUI crashed, file empty)

was the crash immediate after you saw the file name tab update?  or how much do you estimate occurred after the save completed and the file name tab updated before the GUI crashed. did you do anything else in between, did it immediately crash/close, did it seem to freeze for a while then eventually close, etc.

Nicholas Jankowski <nrjank>
Project Member
Mon 02 May 2022 04:40:30 PM UTC, comment #11: 

whether or not there's a temp version depends on quite a few unknowns.  You say windows was updating.  That may or may not matter. did anything else on the system crash? or just the Octave GUI after the save?

looking at the patch made with the intention of preventing some of these data loss events: http://hg.savannah.gnu.org/hgweb/octave/rev/2dc31151ca27

the file save method changed from a 'Qfile file' event (just blindly write the file over the old one) to a QSaveFile event, which is supposed to save in intermediate steps with a temporary file and checks, and to report an error without overwriting if the intermediate steps failed for some reason.

QSaveFile creates a temporary file and then executes a file.commit() to copy the temp file over the active file. the update_window_title event appears to happen after the file.commit. If you saw that tab name change, and if there were no messages before the commit, then it would seem it thinks the save did happen correctly before the crash. If so, the commit includes removing the temporary file, and I'm not sure why you wound up with a 0 byte empty file.

If it changed the title, then also I'm guessing this was a new file and the 'previous version' would have been an empty file if that had ever actually been saved? You said it's local, but are you saving to a Google Drive or One Drive synced location? (trying to think of things other than the save process that can cause odd file-version problems)

@ttl can confirm, but I believe for the released v7.1.0, the GUI uses your system's temporary folder for all temporary files (assuming the tempfile isn't just created right next to the one to save with a unique temp-name)

In octave what do you get for:

>> getenv('temp')


without diving further into how QSafefile works that would be the first place I'd peek for an existing temporary file that might not have been cleared.

Nicholas Jankowski <nrjank>
Project Member
Mon 02 May 2022 03:43:38 PM UTC, comment #10: 

The file was local. AFAIR windows was updating, which may have cause the crash. But whatever the reason, in any ways, Octave should not have overwrite the file without having a temp somewhere. Therefore, do you know where this temp could be, though I've reopen Octave and maybe it is lost now?! Actually Octave should have detected upon reopening that something went wrong and proposed to restore my file ... thanks

sylvain bougnoux <sbougnoux>
Mon 02 May 2022 03:09:05 PM UTC, comment #9: 

@ttl - just confirming, the change in save behavior to try to catch this did make it into 7.1?

that change was made becasue it was noticed that in versions <7.1, if something happened during a save, the entire file could be lost because there was no buffer.  I believe the intent of the new method is to write the new version to a temporary file, after successful write copy that version over the old version, and after a successful copy delete the temporary. 

I don't know at what point the the process the tab filename would update to hit at how far it got.

Is it possible something is interrupting the file write or copy? a problem with temporary file location (assuming its not the local folder)?

Nicholas Jankowski <nrjank>
Project Member
Mon 02 May 2022 08:37:47 AM UTC, comment #8: 

I've suffered the same experiment, a single file I was working one turned completly empty after trying saving (press ctlr+S, file name tab updated by GUI, GUI crashed, file empty). Is there a cache somewhere such that I can recover my file ?

Windows 10, v7.1.0

sylvain bougnoux <sbougnoux>
Fri 22 Apr 2022 05:27:00 PM UTC, comment #7: 

again, offline from user  (it would be helpful if you would use the savannah interface so we don't have to copy/paste emails into the bug record):

Sorry for unclear writing, I meant to say they simply didn't save, not that they reverted to a previous version.

Nicholas Jankowski <nrjank>
Project Member
Fri 22 Apr 2022 05:20:48 PM UTC, comment #6: 

This is very interesting:

other files open in editor ware retained as they were before their last save

Do I understand correctly, octave crashed by closing one modified and not saved file and the other files are changed back to a previous version by this crash? Octave does not keep any old versions in some cache. Are the files sync'ed with google drive or even directly stored on a cloud drive?

Torsten Lilge <ttl>
Project Member
Fri 22 Apr 2022 04:49:45 PM UTC, comment #5: 

Offline from the user:

Your understanding is correct, and the only file that was cleared was the one that I tried closing, other files open in editor ware retained as they were before their last save. As you said it could have been conflict with windows or the backup system I'm using (google drive).

Torsten Lilge <ttl>
Project Member
Fri 22 Apr 2022 03:07:20 PM UTC, comment #4: 

ok, thanks for the info. recent changes were made to gui save behavior to try and prevent loss of data like you're reporting. see [1]. but that specifically was to avoid data being cleared during a save operation.

again, for clarification, all files open had been saved previously and definitely had data written to disk, including the one that crashand on closing? after the crash, did all files have contents cleared, or just the one that you were closing when it crashed?

not sure how octave might have resulted in a data clearing event when not in a save operation other than conflict with something else (file system or network issue?)

[1] https://octave.discourse.group/t/editor-file-saving-process-data-loss-potential/1984

Nicholas Jankowski <nrjank>
Project Member
Fri 22 Apr 2022 02:59:17 PM UTC, comment #3: 

offline from the user:

What I was doing was modifying a function in the editor, then closing the tab by clicking the red cross on the editor windows but before the prompt to save appeared the program becomes unresponsive indefinitely and crashes.

Other files were open on the editor and i was closing one at a time.

Nicholas Jankowski <nrjank>
Project Member
Fri 22 Apr 2022 02:25:56 PM UTC, comment #2: 

when closing, were you also saving the file? (did it prompt to save before closing, etc?) how exactly are you closing the files in the editor? menu? clicking the x, etc? were there other files open at the time or was the one you were closing the only one?

Nicholas Jankowski <nrjank>
Project Member
Fri 08 Apr 2022 05:50:11 PM UTC, comment #1: 

Thank you for the report.

Is the file location on your local disk or some network share or cloud drive? Does the file name or path contain any special characters?

Torsten Lilge <ttl>
Project Member
Fri 08 Apr 2022 05:33:48 PM UTC, original submission:  

When closing individual .m files on the GUI the entire window crashed (happened twice). Not only the progress was lost but the entire file contents before the session (a 0kb file with the correct name was left).

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by sigi_s (Posted a comment)
  • -email is unavailable- added by ttl
  • -email is unavailable- added by ttl
  • -email is unavailable- added by sbougnoux (Posted a comment)
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.

     

     

     

     

    Follow 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-07-05 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2022-05-23 ttl SummaryGUI crashes and clears function files on closing (Windows) GUI crashes and clears function files on closing
    2022-05-22 ttl Dependencies- bugs #62508 is dependent
    2022-05-16 ttl StatusIn Progress Ready For Test
    2022-05-15 ttl StatusNeed Info In Progress
        Operating SystemMicrosoft Windows Any
    2022-05-15 ttl Carbon-Copy- Added sigi_s
        Carbon-Copy- Added mleitner
    2022-05-15 ttl Dependencies- bugs #62467 is dependent
    2022-04-22 mmuetzel Carbon-CopyRemoved 102357 -
    2022-04-11 mmuetzel StatusNone Need Info
    2022-04-08 ttl Severity3 - Normal 4 - Important
        Item GroupNone Segfault, Bus Error, etc.

    Back to the top


    Powered by Savane 3.9