bugGNU Octave - Bugs: bug #56270, Octave 5.1.0 is freeze-y/hang-y on...

 
 

bug #56270: Octave 5.1.0 is freeze-y/hang-y on macOS

Submitted by:  Andrew Janke <apjanke>
Submitted on:  Sun 05 May 2019 09:47:00 PM UTC  
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  5.1.0 Operating System:  Mac OS

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Tue 04 Jun 2019 05:09:03 PM UTC, comment #14: 

I wonder if disabling App Nap (the subject of a different bug report) would help with this one.  It's a long shot, but maybe things stay more in sync if parts of the application (GUI, interpreter) don't go to sleep at different times.

Rik <rik5>
Project Administrator
Fri 10 May 2019 09:46:56 PM UTC, comment #13: 

So it seems better, but not bulletproof, to disable readline.  I guess you should probably release only the CLI version of 5.1.0.  The fixes that jwe is talking about will be on the development branch and will only be a part of version 6.0.

Rik <rik5>
Project Administrator
Tue 07 May 2019 07:58:36 AM UTC, comment #12: 

Hmm. I was playing with it some more, and then it hung, and crashed with a "signal 6"

$ /usr/local/opt/octave-octave-app-no-readline/bin/octave -q --gui                                                          master ✱ ◼
octave exited with signal 6

This was after the Command Window had gotten kind of messed up after I was trying to copy-and-paste some commands in.

Andrew Janke <apjanke>
Tue 07 May 2019 03:58:55 AM UTC, comment #11: 

I did a build of 5.1.0 with `--disable-readline`, and it built, with GUI. Ran _run_test_suite_ and it had no more failures than usual for macOS. (4 failures; that's typical.)

I've been running it for a few hours, and no freezes, so I think it fixed the freezing problem. That suggests the cause is indeed readline interaction.

I don't think we can use `--disable-readline` as a solution, though. The Command Window in the GUI is pretty unusable with readline turned off: no command history recall, the cursor position gets screwed up if you mouse-click anywhere, and it frequently goes wonky and messes up its output or stops responding for a while (without beachballing the app) and complaining about unparseable inputs with what look like control characters.

> I thought if we disabled the gui if you do --no-line-editing that we would have done the same globally if Octave was configured without readline. Should we have done that?


I think that's a call as to whether you want to keep this mode around for debugging purposes. I wouldn't want end users accidentally running in this mode; it messes up the user interaction pretty badly. But it's been useful here to narrow down the freezing problem.

Andrew Janke <apjanke>
Mon 06 May 2019 10:18:35 PM UTC, comment #10: 

I ran _run_test_suite_ and it passed.

Rik <rik5>
Project Administrator
Mon 06 May 2019 10:05:53 PM UTC, comment #9: 

I think most things seem to work.  I can make simple plots.  I did "demo waitbar" and all of them work.

Rik <rik5>
Project Administrator
Mon 06 May 2019 09:33:50 PM UTC, comment #8: 

Oh, I guess my recollection was incorrect. I thought if we disabled the gui if you do --no-line-editing that we would have done the same globally if Octave was configured without readline.  Should we have done that?  Are graphics or other GUI events processed when Octave is waiting for input?

John W. Eaton <jwe>
Project Administrator
Mon 06 May 2019 08:58:40 PM UTC, comment #7: 

jwe is pointing to the ultimate way out.  However, I was just able to build the GUI with --disable-readline on Linux.  It seems to work okay.

Rik <rik5>
Project Administrator
Mon 06 May 2019 08:48:13 PM UTC, comment #6: 

I believe that --disable-readline now also disables the GUI because without readline, we don't currently have a way to process events when Octave is waiting for input at the command prompt.

I've spent a little time looking at the terminal widget replacement.  I hope I can get something preliminary that we can try/discuss/work on together relatively soon.

John W. Eaton <jwe>
Project Administrator
Mon 06 May 2019 08:42:32 PM UTC, comment #5: 

'--no-line-editing' just gives me an error:

$ /Applications/Octave-5.1.0.app/Contents/Resources/usr/opt/octave-octave-app@5.1.0/bin/octave -q --gui --no-line-editing       master
error: --gui and --no-line-editing are mutually exclusive options

I'll try making a `--disable-readline` build when I have some time later today.

Andrew Janke <apjanke>
Mon 06 May 2019 07:30:52 PM UTC, comment #4: 

Long term we have a vision of getting away from the terminal emulator in octave-gui/qterminal.  There are all sorts of problems on Windows platforms as well related to this code.

But in the short term it would be nice to have some sort of fix.  Is there some sort of competition between Readline and the Terminal Emulator for keystrokes?  What happens if you start Ocwave with '--no-line-editing'?  If that has no effect, what happens if you configure octave with '--disable-readline'?

Rik <rik5>
Project Administrator
Mon 06 May 2019 06:36:32 PM UTC, comment #3: 

I think an appropriate tool to use is macOS' "Spindump" creator in the Activity Monitor. This will sample the application and produce stacktraces of where it's spending its time.

Here's one from a recent build of default: https://github.com/octave-app/octave-app/files/2963108/octave-6.0.0-hang-on-close.spindump.zip

A couple from users reporting 5.1.0 hanging upon launch: https://github.com/octave-app/octave-app/files/3088267/octave.5.1.0.hang.on.launch.spindumps.-.2019-04-16.zip

One from myself getting a hang on startup: https://github.com/octave-app/octave-app/files/3088998/octave.5.1.0.beachball.on.startup.-.brewed.-.apjanke.-.spindump.txt.zip

All these spindumps look similar. Here's what I think is the relevant part of the stacktrace:

1000  Vt102Emulation::sendKeyEvent(QKeyEvent*) + 974 (liboctgui.5.dylib + 169502) [0x10f3ad61e]
    1000  Emulation::sendData(char const*, int) + 68 (liboctgui.5.dylib + 232264) [0x10f3bcb48]
      1000  write + 10 (libsystem_kernel.dylib + 124666) [0x7fff7c2876fa]
       *1000  hndl_unix_scall64 + 22 (kernel + 133574) [0xffffff80002209c6]
         *1000  unix_syscall64 + 616 (kernel + 6308424) [0xffffff8000804248]
           *1000  write_nocancel + 218 (kernel + 5536122) [0xffffff800074797a]
             *1000  ??? (kernel + 5536522) [0xffffff8000747b0a]
               *1000  ??? (kernel + 2884439) [0xffffff80004c0357]
                 *1000  VNOP_WRITE + 106 (kernel + 2940314) [0xffffff80004cdd9a]
                   *1000  spec_write + 748 (kernel + 2983340) [0xffffff80004d85ac]
                     *1000  ??? (kernel + 5598603) [0xffffff8000756d8b]
                       *1000  ??? (kernel + 5438214) [0xffffff800072fb06]
                         *1000  lck_mtx_sleep + 126 (kernel + 513278) [0xffffff800027d4fe]
                            *1000  thread_block_reason + 175 (kernel + 558655) [0xffffff800028863f]
                              *1000  ??? (kernel + 562810) [0xffffff800028967a]
                                *1000  machine_switch_context + 205 (kernel + 1590749) [0xffffff80003845dd]

Looks like it's stuck somewhere in the I/O routines for handling keyboard input?

Downstream issues in Octave.app for this:
https://github.com/octave-app/octave-app/issues/24
https://github.com/octave-app/octave-app/issues/23

Andrew Janke <apjanke>
Mon 06 May 2019 09:06:32 AM UTC, comment #2: 

If all that is needed is to find what part of the code the application is stuck in when freezing, it should be easy to
do using apple's "instruments" debugger :

https://help.apple.com/instruments/mac/current/#/dev7b09c84f5

for example attaching a "profiler" instrument to a running instance of Octave then getting a stack trace when it freezes.

unfortunately I cannot help with this myself as I currrently build only without the GUI.

running Octave under an interactive debugger such as gdb or lldb on the other hand is a bit challenging AFAIK

Carlo de Falco <cdf>
Project Member
Mon 06 May 2019 08:30:35 AM UTC, comment #1: 

Marking this bug confirmed since Octave GUI hanging on Mac has the "standard" for a while.

@Andrew: Is there any way to run Octave through gdb (or whatever debugger) under Mac and see where the execution gets stuck? I guess if Octave was stuck into an infinite loop, the OS couldn't notice and the "spinning rainbow beachball" would not fire up. So it looks like a dead-lock that the OS is somewhat able to detect.

Pantxo Diribarne <pantxo>
Project Member
Sun 05 May 2019 09:47:00 PM UTC, original submission:  

Hi, Octave folks,

I think this has been discussed before, but I'm posting an issue for it to have a central place to track this problem.

It seems that the Octave 5.1.0 release has some serious stability issues when running in GUI mode on macOS. The GUI freezes (locks up/hangs) a lot. Sometimes immediately on startup, sometimes a couple seconds after that, sometimes later on when running code. When this happens, the Octave GUI becomes completely unresponsive, you get a "spinnning rainbow beachball" cursor, and you have to Force Kill or `kill -9` the octave process to get it to go away. (Sometimes it hangs so hard even that doesn't work, and I have to log out and back in to get the Octave window to go away. That's a surprise.)

Sebastian Schoeps and I have observed this with Octave.app, and I've also seen this with vanilla Mac Homebrew installations and MacPorts installations. I don't think it's specific to the packaging.

We haven't seen this problem with Octave 4.4.1.

One of the differences between our 4.4.1 and 5.1.0 builds is that 4.4.1 was with Qt 5.11 and 5.1.0 is with Qt 5.12. So I've tried building 5.1.0 with Qt 5.11. Anecdotally, that seems to improve things, but they're still bad: Octave 5.1.0 with Qt 5.11 will hang a lot during usage.

I don't want to be a complainer here: I recognize all the good work that you're doing, and that this is affecting a minority of users. But it seems that Octave 5.x in GUI mode is kind of unusable on the Mac right now. It's bad enough that Octave.app is not releasing a 5.1.0 build yet, and we're considering doing a CLI-only release for 5.1.

Hope we can figure out a solution here.

Andrew Janke <apjanke>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by cdf (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by apjanke (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-05-06 pantxo StatusNone => Confirmed

    Back to the top


    Powered by Savane 3.5