bugGNU Octave - Bugs: bug #54173, Intermittent hang in test suite...

 
 

bug #54173: Intermittent hang in test suite when run from Qt GUI on macOS

Submitter:  Andrew Janke <apjanke>
Submitted:  Sun 24 Jun 2018 06:47:17 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  3 - Low Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Mac OS
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 20 Jul 2018 03:26:25 AM UTC, comment #7: 

Bug #49119 has been resolved on the default branch.  Hence, this bug is as well.  Marking as fixed and closing report.

Rik <rik5>
Group administrator
Fri 29 Jun 2018 06:44:38 PM UTC, comment #6: 

Marking this bug as depending on bug #49119.

Marking as confirmed and lowering the priority since moste users will not be running '__run_test_suite__' invocations, and there is a workaround for those who will.

Still, it would be nice to have a robust test suite which doesn't have odd failures.

The suggestion on bug #49119 to potentially have a user setting that controls whether setting a breakpoint opens the GUI editor would work.

Rik <rik5>
Group administrator
Mon 25 Jun 2018 06:40:12 AM UTC, comment #5: 


> Andrew, as a workaround, enabling "load modified files without asking" in the preferences might also work.


That works! Several _run_test_suite_ runs under this setup, and no hangs.

Thanks!

Andrew Janke <apjanke>
Mon 25 Jun 2018 05:08:44 AM UTC, comment #4: 

Andrew, as a workaround, enabling "load modified files without asking" in the preferences might also work.

Torsten Lilge <ttl>
Group Member
Mon 25 Jun 2018 01:00:39 AM UTC, comment #3: 

I have an okay workaround for this now: if I undock the Editor window and leave it undocked, then only the Editor window will hang, and the main Command Window will keep running and stay responsive, so I can still run the whole test suite and see the results.

Digging deeper: I wonder why Octave thinks the `ftp/dir.m` file has been modified by an external program? The test suite doesn't modify any Octave source files, does it?

The date stamps on these files are well in the past:


[/Applications/Octave-4.4.0.app/Contents/Resources/usr/Cellar/octave-octave-app_4.4.0/4.4.0/share/octave/4.4.0/m/@ftp]
$ ls -l
total 120
-rw-r--r--  1 janke  admin  1229 Jun 24 20:20 ascii.m
-rw-r--r--  1 janke  admin  1190 Jun 24 20:20 binary.m
-rw-r--r--  1 janke  admin  1553 Jun 24 20:20 cd.m
-rw-r--r--  1 janke  admin  1067 Jun 24 20:20 close.m
-rw-r--r--  1 janke  admin  1097 Jun 24 20:20 delete.m
-rw-r--r--  1 janke  admin  1164 Jun 24 20:20 dir.m
-rw-r--r--  1 janke  admin  1046 Jun 24 20:20 disp.m
-rw-r--r--  1 janke  admin  2358 Jun 24 20:20 ftp.m
-rw-r--r--  1 janke  admin  1326 Jun 24 20:20 loadobj.m
-rw-r--r--  1 janke  admin  1606 Jun 24 20:20 mget.m
-rw-r--r--  1 janke  admin  1100 Jun 24 20:20 mkdir.m
-rw-r--r--  1 janke  admin  1359 Jun 24 20:20 mput.m
-rw-r--r--  1 janke  admin  1177 Jun 24 20:20 rename.m
-rw-r--r--  1 janke  admin  1100 Jun 24 20:20 rmdir.m
-rw-r--r--  1 janke  admin   912 Jun 24 20:20 saveobj.m
[/Applications/Octave-4.4.0.app/Contents/Resources/usr/Cellar/octave-octave-app_4.4.0/4.4.0/share/octave/4.4.0/m/@ftp]
$ date
Sun Jun 24 20:57:19 EDT 2018



[/Applications/Octave-4.4.0.app/Contents/Resources/usr/Cellar/octave-octave-app_4.4.0/4.4.0/share/octave/4.4.0/m/miscellaneous]
$ ls -l ls.m
-rw-r--r--  1 janke  admin  4245 Jun 24 20:20 ls.m
[/Applications/Octave-4.4.0.app/Contents/Resources/usr/Cellar/octave-octave-app_4.4.0/4.4.0/share/octave/4.4.0/m/miscellaneous]
$ date
Sun Jun 24 20:58:56 EDT 2018


I was just running the test suite again now, and I got the hang again, but this time it was on `m/miscellaneous/ls.m` instead of `m/@ftp/dir.m`.

Andrew Janke <apjanke>
Mon 25 Jun 2018 12:37:10 AM UTC, comment #2: 

Thanks.

I tried testing the breakpoint case by doing this "magic(3); dbcont; ..." a whole bunch of times:


>> dbstop in magic at 38
ans =  38
>> magic(3);
stopped in /Applications/Octave-4.4.0.app/Contents/Resources/usr/Cellar/octave-octave-app_4.4.0/4.4.0/share/octave/4.4.0/m/special-matrix/magic.m at line 38
38:   n = fix (n);
debug> dbcont
>> magic(3);
stopped in /Applications/Octave-4.4.0.app/Contents/Resources/usr/Cellar/octave-octave-app_4.4.0/4.4.0/share/octave/4.4.0/m/special-matrix/magic.m at line 38
38:   n = fix (n);
debug> dbcont
[...]


It didn't hang.

Andrew Janke <apjanke>
Sun 24 Jun 2018 04:06:40 PM UTC, comment #1: 


> And is it expected that running the test suite pops open these four files in the Editor?


See bug #49119. If it hangs the GUI on macOS, then that may mean that the user operation of setting a breakpoint and calling a function also intermittently hangs the GUI. Can you see whether that is the case?

Mike Miller <mtmiller>
Group Member
Sun 24 Jun 2018 06:47:17 AM UTC, original submission:  

I am building Octave 4.4.0 on macOS 10.13.5, with Qt 5.11.1.

Sometimes, but not always, when I run the test suite in the GUI by entering `__run_test_suite__` in the command window, it ends up hanging the GUI on a non-responsive dialog from the Editor.

What happens is that, every time, part way through the test suite, it will open four files in the editor: dir.m, set.m, quantile.m, and ls.m. I don't know what the full paths to these files are. These will pop up in the editor early in the test suite run, and focus will switch to the editor when this happens.

Sometimes, later on during the run, a dialog will pop up in the editor, saying "It seems that '/Applications/Octave-4.4.0.app/Contents/Resources/usr/Cellar/octave_4.4.0/4.4.0/share/octave/4.4.0/m/@ftp/dir.m' has been modified by another application. Do you want to reload it?". And sometimes, but not always, this dialog will be unresponsive: clicks on its "No" and "Yes" buttons do nothing.

(This weird "/Applications/Octave-4.4.0.app/Contents/Resources/usr" path is because I'm trying to build Octave for redistribution as a Mac app bundle.)

When that dialog is unresponsive, this hangs the GUI. If I have previously undocked the Editor to be a separate window, then it hangs just the editor, and the rest of the test suite proceeds. If the Editor is docked in the main Octave GUI, then the entire thing hangs, and Octave is entirely unresponsive, and all I can do is kill the process.

Can you help out with this hang? It would be nice to be able to run the test suite in the GUI.

And is it expected that running the test suite pops open these four files in the Editor?

Attaching a screenshot of what a hang with a docked Editor window looks like.

Andrew Janke <apjanke>

 

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

Attach Files:
   
   
Comment:
   

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by apjanke (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 group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-07-20 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
        Release4.4.0 dev
    2018-06-29 rik5 Priority5 - Normal 3 - Low
        StatusNone Confirmed
        Dependencies- Depends on bugs #49119
    2018-06-24 apjanke Attached File- Added Octave Qt hung during test suite on macOS 2016-06-24.png, #44421

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code