octave-app
octave-app copied to clipboard
octave-app
Hang in test suite on 4.4.0 beta2: "'.../@ftp/dir.m' has been modified by another application"
A long way in to running the test suite in the GUI, it switches to the editor and pops up this dialog. The dialog is unresponsive, so this effectively hangs Octave.
This is with the Ghostscript fix and the Qt patch to remove FSEventStreamFlushSync() applied.
The files dir.m, set.m, quantile.m, and ls.m are open in the editor when this happened. I didn't start out with any files open in the editor.
I got around this by watching for the editor to pop up, and then manually closing all the files it had open, while the test suite was still running. Ugly hack, but it got me through the test suite so I could see what was still failing.
The dialog hang might be a transient issue. I ran the test suite in the GUI again, with no significant changes, and kept my hands off it, leaving those files up. The dialog didn't appear. Ran __run_test_suite__ a second time in that GUI session without closing any files in the editor, and I got the dialog hang.
Exited, ran a new session, and got the dialog hang on the first run of __run_test_suite__.
The file "ftp.m" is the leftmost tab in the list of files in the editor. There may not be anything special about that file aside from the fact that it's open and first in the list; maybe all the files in the editor are hitting conditions where they are seen as "modified", and ftp.m is just the first one Octave mentions.
When the hang happens, Activity Monitor shows no significant CPU being used by octave-gui, so the test suite is not proceeding.
I've also rerun the test suite and gotten the dialog but not had it be unresponsive, so it doesn't actually hang; you can hit "No" and continue. When this happens, it's only the one dialog about ftp.m, no additional dialogs about the other open files.
Aha! I got the hang running an Octave.app built against the regular, non-patched Qt. Which means maybe we can use our patch after all without introducing additional errors.
In this one, I had the Editor window undocked (something I had done in a previous session), and it hung only the Editor window; the Command Window proceeded to finish the tests, and remained responsive.
I'm not going to close this yet, but I think this is just a bug in the upstream Qt GUI, so it's not a blocker for the release of Octave.app 4.4.0.
Since I've run in to this a few times with non-patched Qt, I'm okay with saying this is not Octave.app-specific, and not a blocker for the 4.4.0 release. Changing this to low priority. Will report upstream.
The editor window initially pops up right around here in the test suite.
libinterp/corefcn/colloc.cc-tst ............................. PASS 12/12
libinterp/corefcn/conv2.cc-tst .............................. PASS 48/51
(reported bug) XFAIL 3
libinterp/corefcn/dassl.cc-tst .............................. PASS 4/4
libinterp/corefcn/data.cc-tst ............................... PASS 1080/1086
(reported bug) XFAIL 6
libinterp/corefcn/debug.cc-tst .............................. PASS 1/1
libinterp/corefcn/defaults.cc-tst ........................... PASS 6/6
libinterp/corefcn/det.cc-tst ................................ PASS 6/6
libinterp/corefcn/dirfns.cc-tst ............................. PASS 1/1
libinterp/corefcn/dlmread.cc-tst ............................ PASS 2/4
(run-time condition) SKIP 2
(reported bug) XFAIL 2
libinterp/corefcn/dot.cc-tst ................................ PASS 22/22
If you close it manually, it pops back up a couple times later on in the test suite.
Related upstream bug, for the opening of the files in the editor in the first place: https://savannah.gnu.org/bugs/?49119
As a workaround, if you just undock the Editor window in your session and leave it that way, then only the Editor window will hang, and the main Octave GUI and Command Window will keep going and stay responsive.
Another workaround: under Settings > Editor, enable "Reload externally changed files without prompt". No hangs under this setting!
Per https://savannah.gnu.org/bugs/index.php?54173#comment4.
I'd say that this bug should not stop us from a release. It's known upstream and it probably affects no user (running the tests manually is not a common thing).
I agree.
Moving the milestone for this to "The Future" to indicate it's not a blocker for 4.4.0.
The hang no longer happens for me with Octave 4.4.1. Looks like it was fixed upstream.
Closing as fixed.
@apjanke, I'm also facing the same issue. Is there any way to resolve it? Also, the 5.2.0 beta version has the same issue.
@PRUBHTEJ Can you try the new 6.0.90 Release Candidate beta and see if it happens there? https://github.com/octave-app/octave-app/releases/tag/v6.0.90-rc1
We're far enough behind upstream's releases now that I'm kind of dubious about getting more fixes into the 4.x series.
Sure!! Just to let you know, I'm facing the same issue with 5.x beta as well.
Closing this ticket since 4.x is basically EOL now; focusing on 6.x and 8.x; see https://github.com/octave-app/octave-app/issues/243.