bugGNU Octave - Bugs: bug #50025, Octave window freezes when I quit...

 
 

bug #50025: Octave window freezes when I quit Octave GUI

Submitter:  Daniel <trez>
Submitted:  Wed 11 Jan 2017 02:08:30 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  3 - Low Item Group:  Segfault, Bus Error, etc.
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

Sun 15 Nov 2020 08:26:03 PM UTC, comment #72: 

Thank you Andrew,

new command got Octave 6 installed in ~12 minutes. Got iMac upgraded to v 11.0.1 Big Sur as well.

Command+Q was grayed out for quite some time, so I was concerned one problem was replaced by another, but Octave kept functioning normally, there was no spinning pinwheel, and finally Command+Q became available again (whatever app was doing).

Appreciate the work of all the developers. Matlab is still an expensive option to have for personal use, and Octave seems to be just as good so far in initial use.

Thank you !

Alexey <seattle_2020>
Thu 12 Nov 2020 05:58:22 PM UTC, comment #71: 

Are you sure it's stuck? Looks like it's building Qt here, and that can take a couple hours.

If you don't want to build the special patched Qt, you can do:

brew install octave-app/octave-app/octave@6.0.90

instead, which will make use of the pre-built "bottled" qt from homebrew-core.

Andrew Janke <apjanke>
Thu 12 Nov 2020 05:40:23 PM UTC, comment #70: 

Attempts to install Octave 6 (having uninstalled Octave 5.2 that crashes 5 minutes after launch) result in stuck "make" command after ~ 5 minutes of installation activity. Interestingly HD noise (spinning drive) appears at the moment installation gets stuck.
Any help would be greatly appreciated.
Thank you

===Hardware ref:
macOS Catalina v. 10.15.7
iMac Retina 5 27", 2017

=== screen ref:
alexey_imac@ALEXEYs-iMac ~ % brew ls --versions octave
alexey_imac@ALEXEYs-iMac ~ % brew install octave-app/octave-app/octave-octave-app@6.0.90
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 2 taps (homebrew/core and homebrew/cask).
==> New Formulae
flux                                     xorgrgb
==> Updated Formulae
Updated 44 formulae.
==> New Casks
macx-video
==> Updated Casks
android-file-transfer                    plex
busycal                                  protonmail-bridge
eloston-chromium                         pycharm-ce-with-anaconda-plugin
epichrome                                pycharm-with-anaconda-plugin
find-any-file                            sequel-ace
google-cloud-sdk                         subler
graphicconverter                         swish
iexplorer                                toolreleases
malus                                    transcribe
microsoft-edge                           trezor-bridge
omnifocus                                turbo-boost-switcher
omnigraffle                              use-engine
omnioutliner                             vivaldi
omniplan

==> Installing octave-octave-app@6.0.90 from octave-app/octave-app
==> Downloading https://raw.githubusercontent.com/octave-app/formula-patches/0ff
Already downloaded: /Users/alexey_imac/Library/Caches/Homebrew/downloads/ffb85c8ba82ede820f116f1ea36ea4678d4ce1c23da2968af2db8e3590250fec--disable-FSEventStreamFlushSync.patch
==> Downloading https://download.qt.io/official_releases/qt/5.15/5.15.1/single/q
Already downloaded: /Users/alexey_imac/Library/Caches/Homebrew/downloads/bbb4dae1de0205b5bf7d92b88f39540433452b5a8029a9827139c8611d7aeac5--qt-everywhere-src-5.15.1.tar.xz
==> Downloading http://apps.jcns.fz-juelich.de/src/libcerf/libcerf-1.5.tgz
Already downloaded: /Users/alexey_imac/Library/Caches/Homebrew/downloads/5a94c4a074674a61e21642882831a899566e05f752fd8dea04bdec60adbcc4cc--libcerf-1.5.tgz
==> Downloading https://downloads.sourceforge.net/project/gnuplot/gnuplot/5.4.0/
Already downloaded: /Users/alexey_imac/Library/Caches/Homebrew/downloads/85f94a0b3fc696f5be17e436649c18be9e8f57f1a5983b6c97d571917c842e56--gnuplot-5.4.0.tar.gz
==> Downloading https://homebrew.bintray.com/bottles/gnu-tar-1.32.catalina.bottl
Already downloaded: /Users/alexey_imac/Library/Caches/Homebrew/downloads/41448411ff6152900183188c83d1172204d4d311cba2084d06db85147e54834e--gnu-tar-1.32.catalina.bottle.1.tar.gz
==> Downloading https://sourceforge.net/projects/librsb/files/librsb-1.2.0.8.tar
Already downloaded: /Users/alexey_imac/Library/Caches/Homebrew/downloads/7ac3e369329129fcdea14391de746632468d9a9ddd9cb785412532dc25303b4f--librsb-1.2.0.8.tar.gz
==> Downloading https://homebrew.bintray.com/bottles/openjdk-15.0.1.catalina.bot
Already downloaded: /Users/alexey_imac/Library/Caches/Homebrew/downloads/355a80454da4f90367777654ba877fba8c22ddfca371cedc39c3ef0724a2b334--openjdk-15.0.1.catalina.bottle.tar.gz
==> Downloading https://homebrew.bintray.com/bottles/cfitsio-3.490.catalina.bott
Already downloaded: /Users/alexey_imac/Library/Caches/Homebrew/downloads/97be7bd5446509c6778ef24d6b7dc6d9d2685fbe32204887a9fcf190f27b88de--cfitsio-3.490.catalina.bottle.tar.gz
==> Downloading https://homebrew.bintray.com/bottles/gsl-2.6.catalina.bottle.tar
Already downloaded: /Users/alexey_imac/Library/Caches/Homebrew/downloads/f85bf676bba393cca3bebbd8e04ef143d139b594f4a1b6fe3cfea0a46427db85--gsl-2.6.catalina.bottle.tar.gz
==> Downloading https://download.osgeo.org/proj/proj-datumgrid-1.8.zip
Already downloaded: /Users/alexey_imac/Library/Caches/Homebrew/downloads/a255dbc96f75c2e1dc9670773f9e09ecf29a75f17dcabdca1224c26d94de0a6d--proj-datumgrid-1.8.zip
==> Downloading https://download.osgeo.org/proj/proj-5.2.0.tar.gz
Already downloaded: /Users/alexey_imac/Library/Caches/Homebrew/downloads/0c7ca7d1570fa13b63542cc1dda45ed93dd459250992cf7594d5834d8d1c1516--proj-5.2.0.tar.gz
==> Downloading https://homebrew.bintray.com/bottles/zeromq-4.3.3.catalina.bottl
Already downloaded: /Users/alexey_imac/Library/Caches/Homebrew/downloads/e05ac23a79b57ceac2c584c982575466902588bdae8fbffb904fe471ec8377b3--zeromq-4.3.3.catalina.bottle.tar.gz
==> Downloading https://www.riverbankcomputing.com/static/Downloads/QScintilla/2
Already downloaded: /Users/alexey_imac/Library/Caches/Homebrew/downloads/85ad130acea7213397d62b59315a3da6867d41e049eeca3679a0ab39e3acd0c9--QScintilla-2.11.5.tar.gz
==> Downloading ftp://alpha.gnu.org/gnu/octave/octave-6.0.90.tar.lz
Already downloaded: /Users/alexey_imac/Library/Caches/Homebrew/downloads/192615243190e76b914909286a9f64d94b2bb3c1fc79341a0874f21432a0ce52--octave-6.0.90.tar.lz
Warning: A newer Command Line Tools release is available.
Update them from Software Update in System Preferences or run:
  softwareupdate --all --install --force

If that doesn't show you an update run:
  sudo rm -rf /Library/Developer/CommandLineTools
  sudo xcode-select --install

Alternatively, manually download them from:
  https://developer.apple.com/download/more/.

==> Installing dependencies for octave-app/octave-app/octave-octave-app@6.0.90: qt-octave-app, gnuplot-octave-app, gnu-tar, librsb, openjdk, cfitsio, gsl, proj@5, zeromq and qscintilla2-octave-app
==> Installing octave-app/octave-app/octave-octave-app@6.0.90 dependency: q
Warning: A newer Command Line Tools release is available.
Update them from Software Update in System Preferences or run:
  softwareupdate --all --install --force

If that doesn't show you an update run:
  sudo rm -rf /Library/Developer/CommandLineTools
  sudo xcode-select --install

Alternatively, manually download them from:
  https://developer.apple.com/download/more/.

==> Patching
==> Applying disable-FSEventStreamFlushSync.patch
patching file qtbase/src/corelib/io/qfilesystemwatcher_fsevents.mm
Hunk #1 succeeded at 331 (offset 1 line).
==> ./configure -verbose -prefix /usr/local/Cellar/qt-octave-app/5.15.1 -release
==> make

Alexey <seattle_2020>
Sat 07 Nov 2020 02:30:08 PM UTC, comment #69: 

Thank you for checking.

Closing as fixed.

Markus Mützel <mmuetzel>
Group administrator
Sat 07 Nov 2020 12:34:07 PM UTC, comment #68: 

Excellent. That probably means this can be closed as fixed, since the app 6 RC does not include this patch.

Andrew Janke <apjanke>
Sat 07 Nov 2020 12:31:01 PM UTC, comment #67: 

Thank you very much! I did not know that there is an app version 6.

I installed this one:
https://github.com/octave-app/octave-app/releases/tag/v6.0.90-rc1

and the bug is gone.

Christoph <chfriedrich>
Sat 07 Nov 2020 12:12:39 PM UTC, comment #66: 

You can find "app" versions of Homebrew formulae for Octave 5.2.0 and the Octave 6 Release Candidate in the octave-app/octave-app tap here: https://github.com/octave-app/homebrew-octave-app. The 5.2.0 version includes the patch, and in our testing of 6 RC, it's no longer needed.

To install the "app" version of Octave 6 RC via brew, do:

$ brew install octave-app/octave-app/octave-octave-app@6.0.90

If you don't want to spend the time running the build (it'll probably take an hour or more), a 6.0.90 RC distribution of Octave.app is available here: https://github.com/octave-app/octave-app/releases/tag/v6.0.90-rc1

> can you please include it in the normal homebrew version?


GNU Octave has no control over which patches are included in core Homebrew formulae; their criteria is generally "at least submitted, and preferably accepted, upstream". You could ask the Homebrew maintainers about this at https://github.com/homebrew/homebrew-core.

Andrew Janke <apjanke>
Sat 07 Nov 2020 11:02:02 AM UTC, comment #65: 

@Christoph: Does this still occur with a release candidate for Octave 6? IIUC there is a homebrew rule for it...

Markus Mützel <mmuetzel>
Group administrator
Sat 07 Nov 2020 10:05:54 AM UTC, comment #64: 

No, this bug still exists exactly as described here!

I am using the newest homebrew version, 5.2.0_10.

Since the patch seems to work, can you please include it in the normal homebrew version? It is included in the app version, but this is the older 4.4.1 version.

Christoph <chfriedrich>
Thu 08 Oct 2020 04:08:34 AM UTC, comment #63: 

Can we close this bug report?  I think shutdown procedures have been much improved and this bug may no longer be present.

Rik <rik5>
Group administrator
Wed 03 Jun 2020 03:00:53 PM UTC, comment #62: 

It's working for me most of the time, though I have occasionally noticed comments in the tracker that I did not see in email.  I'm not sure what's causing that problem.  As savannah users we don't have control over it or a way to fix it.  We will need help from the savannah sysadmins.

John W. Eaton <jwe>
Group administrator
Wed 03 Jun 2020 02:52:17 PM UTC, comment #61: 

This is a test comment just to see if Savannah email notification is working.

Andrew Janke <apjanke>
Thu 21 May 2020 04:54:56 AM UTC, comment #60: 

From bug #58409 original submission:

> I've octave installed through homebrew. Starting the gui version of octave works fine, but when trying to exit, the cursor switches to the rotating disk in rainbow colors, and the octave window never finishes (I've waited for at least 10 minutes). Only a "killall -9 octave-gui" will get rid of the process.
>
> I've also installed octave from source using
>     brew reinstall --build-from-source octave
> and see the same result. Therefore, I send this report to octave and not homebrew.
>  
> Starting the cli version of octave does not show this problem.
> I'm running macOS High Sierra v 10.13.6, with XQuartz 2.7.11, on a MacBook Pro Retina (late 2013)
>
> Attached [in bug #58409] is the error log. oc-mac-error.report.txt (file #49129)
>
> I've also submitted a bug report to homebrew
>   https://github.com/Homebrew/homebrew-core/issues/55007
> I do not know which one is more appropriate.
>



Kai Torben Ohlhus <siko1056>
Group Member
Wed 16 Oct 2019 12:11:41 AM UTC, comment #59: 

I'm also seeing a crash at exit when executing a script file (related to bug #56952, it seems) that also appears to be "fixed" by not connecting m_interpreter_qobj->octave_finished_signal to m_main_thread->quit and making the call to m_main_thread->quit directly in the base_qobject::handle_octave_finished function.

Printing "\n" to stderr doesn't seem to be needed.  What does that do on MacOS?  Is it needed to actually print the newline at exit?

In any case, it looks like there is some general call sequence and threading issue here.  I pushed the following changeset:

  http://hg.savannah.gnu.org/hgweb/octave/rev/1a4defb4dfc2

John W. Eaton <jwe>
Group administrator
Sat 12 Oct 2019 05:27:41 PM UTC, comment #58: 

Thank you so much!  You cleared it up for me. Excellent answer.

Hannes <sasaas>
Sat 12 Oct 2019 02:25:21 PM UTC, comment #57: 

@Hannes: The patch file includes the paths to the files to be patched. It needs to be applied to the Octave source tree before you build Octave, not to the installed built Octave.

Note that the latest patch only works against the recent versions of the default branch from the Octave source tree. For previous releases, you need to use one of the older versions of the patch. The version at https://savannah.gnu.org/support/download.php?file_id=45382 will apply to either Octave 4.4.1 or 5.1.0. And if you're building from the current head of the master branch, you don't need to use the patch at all, since it has been merged.

If you're installing Octave with Homebrew and want to use this patch, I suggest you use the formulae from the Octave.app project's octave-app/octave-app tap (https://github.com/octave-app/homebrew-octave-app) instead of core Homebrew. Our "octave-octave-app*" formulae come with this patch already applied, and are maintained by the Octave.app maintainers so you don't have to worry about anything. Do this:

brew tap octave-app/octave-app
brew install octave-octave-app

or:

brew install octave-octave-app@4.4.1

I would actually recommend using that 4.4.1 version, since the Octave 5.x GUI is still freezy on macOS.

Andrew Janke <apjanke>
Sat 12 Oct 2019 01:05:57 PM UTC, comment #56: 

Which specific file needs to be patched in this case? Or in which directory do I have to look for it? (home-brew installed) I tried to run the patch being in the root directory.

Hannes <sasaas>
Fri 11 Oct 2019 05:51:10 PM UTC, comment #55: 

Changed the priority to "Low".

Rik <rik5>
Group administrator
Fri 11 Oct 2019 05:49:06 PM UTC, comment #54: 

Thank you!

I vote that we lower the priority but leave this bug open, because it's still a mystery why this freeze is occurring or why this workaround works.

Andrew Janke <apjanke>
Fri 11 Oct 2019 05:47:17 PM UTC, comment #53: 

I cleaned up the patch to use Octave coding conventions and added an explanation to the commit message and checked everything in here (https://hg.savannah.gnu.org/hgweb/octave/rev/1bbeb8aeb1cd).

What shall we do with this bug report now?  Close it?  Lower the priority since a workaround is in place?  Something else?

Rik <rik5>
Group administrator
Fri 11 Oct 2019 05:08:58 PM UTC, comment #52: 

Here's a version that restricts the changes to macOS only: https://savannah.gnu.org/bugs/download.php?file_id=47650

Andrew Janke <apjanke>
Fri 11 Oct 2019 04:48:56 PM UTC, comment #51: 

I agree that this must be annoying for Mac users.

@Andrew: Can you modify the patch to apply only to Mac users (i.e., protect your changes with #ifdef).  It will be safer that way since we don't fully understand the mechanism for why fprintf is required and we shouldn't perturb existing systems (Linux, Windows) in case it has a malign effect.

Rik <rik5>
Group administrator
Fri 11 Oct 2019 04:34:04 PM UTC, comment #50: 

The patch no longer applies to the head of default. Here's an updated patch that does exactly the same thing, just updated to apply cleanly.

https://savannah.gnu.org/bugs/download.php?file_id=47649

Andrew Janke <apjanke>
Sun 11 Aug 2019 09:54:24 PM UTC, comment #49: 

Basically, at the command line go to the base (trunk) of the hierarchy one is interested in patching (say, the Octave base directory) and then type the "patch" command and redirect the file as input, e.g.,

linux> patch -p[num] < nice_bug_fix.patch

The number concerns the level at which the patch file paths should be trimmed back.  I.e., at what level did the original programmer make the diff-file from?  Start with -p0.  If it complains that the file can't be found to patch with, try -p1.

These patches are probably rather out of date, so might not patch well.  This whole issue should maybe be revisited and thought of in terms of what would be the best exit design for the latest code.

Dan Sebald <sebald>
Sun 11 Aug 2019 08:25:13 PM UTC, comment #48: 

How do you apply these patches? I've already watched some tutorials, but my amateurish skills wouldn't allow me to succeed. Eventually the terminal asks for the target file to be patched or so and I don't know where I can find it or what to type in.

Hannes <sasaas>
Wed 13 Mar 2019 10:51:05 PM UTC, comment #47: 

Maybe we could get this merged if we special-cased the workaround to just macOS? It's quite a pain to be working with the default branch and having Octave hang every time it's run. On my Mac, it often hangs so hard that Force Quit doesn't work and I have to log out and back in to get rid of the dead windows.

Here's a version of the patch that #ifdefs the workaround to macOS: file #46530:  octave-qt_alternate_quit_macos-apj-20190313.patch

(This patch also seems to clear up the issue with the non-GUI version of octave crashing during the document generation step of the build.)

Andrew Janke <apjanke>
Wed 13 Mar 2019 06:56:57 PM UTC, comment #46: 

Patch is still needed on default, too.

Here's a spindump of a hang from a freshly-built default Octave (hg id: d94876e7a0aa).

file #46521:  octave-6.0.0-hang-on-close-truncated.spindump.zip

Andrew Janke <apjanke>
Tue 05 Mar 2019 02:48:02 AM UTC, comment #45: 


> Is a patch still needed with the 5.1.0 release?


The patch is still needed in my testing on Mac, too. Octave.app will be including it in our 5.1.0 installer.

Andrew Janke <apjanke>
Sun 03 Mar 2019 10:34:43 PM UTC, comment #44: 

I agree it is small. I think Dan proposed a working diff that turned out to be fragile. Later adjustments and experiments brought it to its current state.

It requires the fprintf to stderr to function, which (imo) is an indication that we don't know what is wrong or how to fix it properly.

So it is small, but not understood or proper.

Two additional patches are also needed for MacOS. They are attached to bug# 55268.

https://savannah.gnu.org/bugs/index.php?55268#comment42

My impression is that our use of Qt is fragile on macOS.

If Pantxo's print_fbo2.patch doesn't cause problems for Linux or Windows, then I'm happy to see it applied.

Carlo's open_kEClIYyW.patch is another example of a "short" / misunderstood fix. If we submit one, maybe submit all. But that takes us down a slippery slope.

Ben Abbott <bpabbott>
Group Member
Sun 03 Mar 2019 07:44:30 PM UTC, comment #43: 

The patch is really small.  If there is no other way to resolve this, maybe we should put the changes you have in comment #40 under #ifdef protection so they are only used on Mac platforms.

Rik <rik5>
Group administrator
Sun 03 Mar 2019 03:51:38 PM UTC, comment #42: 

@Rik,

Yes. I still need the patch.

Ben Abbott <bpabbott>
Group Member
Sun 03 Mar 2019 06:44:53 AM UTC, comment #41: 

@Ben: Is a patch still needed with the 5.1.0 release?

Rik <rik5>
Group administrator
Thu 08 Nov 2018 05:37:45 AM UTC, comment #40: 

Updated patch

(file #45382)

Ben Abbott <bpabbott>
Group Member
Thu 06 Sep 2018 09:14:25 PM UTC, comment #39: 

You can now install octave with gui on macOS with: homebrew install octave --with-qt or homebrew reinstall octave --with-qt (builds, so a bit slow). However, it hangs when you quit and you have to force quit as well as find and kill the process with ps aux | grep octave.

Since it's easier to install hopefully that will make it easier for someone to debug!

Henry Schreiner <henryiii>
Thu 05 Apr 2018 02:49:44 AM UTC, comment #38: 

Opps, I missed a part. Trying again.

(file #43807)

Ben Abbott <bpabbott>
Group Member
Wed 04 Apr 2018 04:20:32 AM UTC, comment #37: 

I can confirm the clumsy patch is still needed. However, if it is not applied, the gui will not run (so no freeze on exit). I'm attached a patch rebased to default.

(file #43793)

Ben Abbott <bpabbott>
Group Member
Tue 03 Apr 2018 09:12:02 PM UTC, comment #36: 

I can't remember the issue with this one real well.  It was Mac OS, and I wasn't sure it was a real good fix.  I think it might be best to go back and confirm the original bug, the have a second look from there.  Maybe some changes along the way have fixed this or made it more apparent what is wrong.

Dan Sebald <sebald>
Tue 03 Apr 2018 08:45:59 PM UTC, comment #35: 

Dear Dan & Ben,

is that something that can make it into 4.4?

Sebastian

Sebastian <sschoeps>
Mon 15 Jan 2018 12:16:02 PM UTC, comment #34: 

@Dan

Unfortunately, the fprintf(stderr, "\n") is still needed.

Ben Abbott <bpabbott>
Group Member
Mon 15 Jan 2018 06:57:41 AM UTC, comment #33: 

You may be on to something, but I'm hoping you meant that this patch works without the need of the fprintf() call, i.e., no


+  /* fprintf to stderr is needed by macOS */
+  fprintf(stderr, "\n");


If I remove the above line from the patch you posted, Octave GUI still exits fine in linux--no surprise, I guess.

I probably disregarded this connection:


-  connect (m_main_thread, SIGNAL (finished (void)),
-           m_main_thread, SLOT (deleteLater (void)));


thinking it just some innocuous extraneous call at worst.  However, that might have been the source of the problem all along.  What this connection means is once the main thread finishes, it's going to emit a signal that the main thread (itself) should delete later.  That does seem like an odd construct, though, doesn't it?  I mean, this might be an unconventional thing to do, and as such the Qt developers may have a bug in this construct that went untested.  It's conceivable that m_main_thread can't change the status of delete-later once it has reached the stage of issuing a finished().

...

In fact, I'm looking at the documentation for Qt here (it's the link from post #3):

http://doc.qt.io/qt-5/qthread.html#details

Look at the second method they suggest for doing this worker-thread communication.  It's the worker thread that has its finished() signal connected to its deleteLater() slot:


void MyObject::startWorkInAThread()
{
    WorkerThread *workerThread = new WorkerThread(this);
    connect(workerThread, &WorkerThread::resultReady, this, &MyObject::handleResults);
    connect(workerThread, &WorkerThread::finished, workerThread, &QObject::deleteLater);
    workerThread->start();
}


and, importantly, the WorkerThread must be subclassed from QThread, i.e., derived from.

In Octave, it looks like the main thread is connected to itself (not the worker thread) and the main thread is just a QThread, not a derived class.  The current configuration is probably some unconventional thing for which it might be no surprise (to the designers perhaps) that this fails.

Anyway, let me know if your revised patch still works if the fprintf() is removed.  If not, we may have to redo this worker-thread setup as much as possible similar to the examples given in the link above.  (Threads are tricky, not deviating is a good idea.)

Dan Sebald <sebald>
Mon 15 Jan 2018 04:30:51 AM UTC, comment #32: 

@Dan, I'm just blindly experimenting and found the change below also allow Octave to exit normally. I don't have any insight, but maybe you ore someone else will.


diff --git a/libgui/src/main-window.cc b/libgui/src/main-window.cc
--- a/libgui/src/main-window.cc
+++ b/libgui/src/main-window.cc
@@ -215,12 +215,6 @@ main_window::main_window (QWidget *p, oc
   connect (m_interpreter, SIGNAL (octave_finished_signal (int)),
            this, SLOT (handle_octave_finished (int)));

-  connect (m_interpreter, SIGNAL (octave_finished_signal (int)),
-           m_main_thread, SLOT (quit (void)));
-
-  connect (m_main_thread, SIGNAL (finished (void)),
-           m_main_thread, SLOT (deleteLater (void)));
-
   m_interpreter->moveToThread (m_main_thread);

   m_main_thread->start ();
@@ -1568,6 +1562,10 @@ main_window::handle_octave_ready (void)
 void
 main_window::handle_octave_finished (int exit_status)
 {
+  /* fprintf to stderr is needed by macOS */
+  fprintf(stderr, "\n");
+  m_main_thread->quit();
+  m_main_thread->deleteLater();
   qApp->exit (exit_status);
 }


Ben Abbott <bpabbott>
Group Member
Thu 11 Jan 2018 06:01:56 AM UTC, comment #31: 

OK, let me think about this.

Dan Sebald <sebald>
Thu 11 Jan 2018 05:32:43 AM UTC, comment #30: 

@Dan - Good call. Removing the wait also works.

I also expect that the fprintf() is fixing an existing problem, but have no idea how to track it down.

Ben Abbott <bpabbott>
Group Member
Thu 11 Jan 2018 05:20:47 AM UTC, comment #29: 

I'm sure this still works because it was an


+fprintf(stderr, "HANDLE_OCTAVE_FINISHED: 111111111111111111111111111111111111111111\n");


before and now an


+  fprintf(stderr, "\n");


However, this doesn't seem like a comfortable fix to the problem, i.e., placing an inexplicable fprintf() prior makes it work.

Perhaps the fprintf() is doing something like flushing a buffer somewhere as a side effect.  What happens when removing the wait() and just have the fprintf() then quit()?  Freeze or exit?

Dan Sebald <sebald>
Thu 11 Jan 2018 04:10:50 AM UTC, comment #28: 

I'm now able to build with Qt5 using the default branch. The Qt patch ((file #41891) prevents the hang on exit, but the 1st debug fprintf(stderr,...) is needed to prevent the GUI from hanging on exit. I'm attaching a simpler version of the patch which reduces the fprintf content to \n.

At this point, I think we need a Linux user to test the patch to confirm that it doesn't break anything.

(file #42886)

Ben Abbott <bpabbott>
Group Member
Wed 10 Jan 2018 05:41:42 AM UTC, comment #27: 

The Qt patch (file #41891) works for me with Qt4 using the default branch. However, if I remove the debug fprints, it does not work (i,e, it hangs on exit). The later patches also hang for me on exit.

Ben Abbott <bpabbott>
Group Member
Mon 20 Nov 2017 10:31:31 PM UTC, comment #26: 

I think we could use the Qt::BlockingQueuedConnection if the signal were originating from the main window of the GUI.  So perhaps what we need is something like

command_interpreter SIGNAL octave_finished_signal
goes to
main_window SLOT (initiate_quit???)

and the the main window has a connection

main_window, SIGNAL (quitmainthread???)
goes to
main_thread SLOT (quit ()) with Qt::BlockingQueuedConnection

That is, the main_window is the one that always quits the main_thread and then waits on it.

Dan Sebald <sebald>
Mon 20 Nov 2017 10:23:36 PM UTC, comment #25: 

I may have placed the connection classification on the wrong signal/slot pair.  Not sure.  The problem is that it's now the interpreter issuing this signal (octave_finished_signal (int)), but the interpreter lives in the main_thread (via move) so I'm not sure if Qt::BlockingQueuedConnection even applies anymore because signal/slot in the same thread are not queued.

So, it may be that we have to go back to a setup similar to the original patch in which the quit/wait is done via the main window.

(file #42446)

Dan Sebald <sebald>
Mon 20 Nov 2017 10:03:05 PM UTC, comment #24: 

It looks as though on the stable branch that JWE shuffled some code around and associated the m_main_thread with the octave_qt_link object.  Hence m_main_thread is no longer accessible.

So, I've tried the idea from Panxto, which is to make the connection between finish() and deleteLater() blocking, which I'm hoping is essentially the same this as waiting.  So, here's a patch to try for the stable branch.  And perhaps if that works in stable it can easily be incorporated in default branch.

(file #42445)

Dan Sebald <sebald>
Mon 20 Nov 2017 09:34:25 PM UTC, comment #23: 

jwe: I made a fresh  checkout of the stable branch and compiled it (it still calls itself 4.2.1, right?). Octave still freezes on exit if one has plotted before.

Sebastian <sschoeps>
Mon 20 Nov 2017 08:53:15 PM UTC, comment #22: 

Sebastian: I'd like to know what happens with the current stable branch sources without any patches applied.

John W. Eaton <jwe>
Group administrator
Mon 20 Nov 2017 08:40:40 PM UTC, comment #21: 


>Sebastian, we are wondering if the current development branch has the issue with
> freezing at exit in MacOS corrected or if there still needs to be some kind of patch.
> Would it be easy for you to test the most recent development branch that is going to
> form the basis for 4.2.2?


Sure. Will do. However, I assume Mike was rather sceptical that your patch can be backported (see comment #16).

Sebastian <sschoeps>
Mon 20 Nov 2017 08:31:52 PM UTC, comment #20: 

Sebastian, we are wondering if the current development branch has the issue with freezing at exit in MacOS corrected or if there still needs to be some kind of patch.  Would it be easy for you to test the most recent development branch that is going to form the basis for 4.2.2?

Dan Sebald <sebald>
Thu 12 Oct 2017 08:13:48 AM UTC, comment #19: 

Oh yeah, you're right.  I forgot that the signal type can be altered when making the Qt connection.  The wait of quit/wait construct effectively creates a lock (I think, but haven't explored).  Is there any difference between the two constructs?  I'm not sure.  Nonetheless, the quit/wait construct is an example as shown in the Qt documentation, so it's got that going for it. 

I'm open to the blocking queued signal approach, though, but at the same time prefer not experimenting too much with something that seems to work, at least for now, in an otherwise historically fragile exit process.  If/when the exit is overhauled to be more robust is a better time for experimenting.

Dan Sebald <sebald>
Mon 09 Oct 2017 01:52:45 PM UTC, comment #18: 

@Dan:

>> The signal/slot connection doesn't have a means for waiting


I don't know if it is relevant here since since I did not look into this at all, but ther is a way to have the signal function return only when the slot has returned. The connection must be made in queud mode:
 connect (signal,..., Qt::BlockingQueuedConnection)

There is a requirement though, the signaling thread is then locked until the slot thread has returned: it means that the slot thread can't request some operation to be done in the signal thread because it would lead to a dead lock.

Pantxo Diribarne <pantxo>
Group Member
Sat 07 Oct 2017 05:55:13 PM UTC, comment #17: 

Correct, in all likelihood the QThread::wait is the necessary item.  The signal/slot connection doesn't have a means for waiting.

Hopefully the next Octave release isn't too far off.  There have been quite a few seemingly critical bugs following the most recent release, so it would be nice to get something more stable out there.

Dan Sebald <sebald>
Sat 07 Oct 2017 05:33:31 PM UTC, comment #16: 

It's unlikely that this could be backported to the stable branch, but anyone is welcome to try. There has already been very significant refactoring work done in the GUI on the development branch before this point.

As far as applying this patch to the default branch, I see no problems with it. I suppose the relevant change here is the QThread::wait for completion before destroying the thread.

Mike Miller <mtmiller>
Group Member
Tue 03 Oct 2017 02:12:01 AM UTC, comment #15: 

I can't make changes in the canonical repository.  It's a very small changeset, so backporting doesn't seem complicated if you think it would help.  (Most of the main developers don't work much with MacOS.)  However, it would probably be good to make sure several MacOS testers feel comfortable the fix works before backporting.

Dan Sebald <sebald>
Mon 02 Oct 2017 07:15:54 PM UTC, comment #14: 

I'd also be interested in seeing a backport. Last week, I ran into this issue in front of my physics class, with octave 4.2.1, built using MacPorts.

Marius Schamschula <mschamschula>
Sun 01 Oct 2017 06:13:20 PM UTC, comment #13: 

@Dan: did you consider a backport?

Sebastian <sschoeps>
Sun 01 Oct 2017 05:20:31 PM UTC, comment #12: 

OK, thanks for the clarification.  I don't know the MacOS build process, but it sounds like it takes some work and finding another user to test might be difficult.  It's up to Mike how to proceed.

Dan Sebald <sebald>
Sun 01 Oct 2017 05:03:32 PM UTC, comment #11: 


>Or is it the case that you think you didn't have patch 41889 applied and built cleanly in the first place, but now it seems to work?


sorry for the confusion. I am pretty sure that my first attempt was not a clean build. Now, I have verified that both versions of your patch work for me and I always started from a fresh checkout :)

Sebastian <sschoeps>
Sun 01 Oct 2017 04:56:25 PM UTC, comment #10: 

Mike is on this thread, so he'd be the one to incorporate the patch if it works.  I'm a bit unclear about which patch works because you initially wrote something about it not solving the bug.  Patch 41889 and 41891 are effectively the same, the latter having a little extra debug info.  So if the latter works and the former doesn't, then that is simply a matter of the extra fprintfs slowing things down and not addressing the main problem.  Or is it the case that you think you didn't have patch 41889 applied and built cleanly in the first place, but now it seems to work?

Dan Sebald <sebald>
Sun 01 Oct 2017 04:13:49 PM UTC, comment #9: 

I checked on several machines with various qt and macOS versions. The patch works for me! I strongly suggest to push it to the development branch. I tried to back port it but I was not able. @Dan: would that be possible?

Sebastian <sschoeps>
Tue 26 Sep 2017 07:31:40 AM UTC, comment #8: 

Well, thread timing bugs are some of the stranger bugs.  When things aren't coded according to the design, changing things slightly in either thread can "fix" things or "break" them.

It's odd that you don't see any of the fprintf(stderr,...) output.  If you are using "exit" at the command line to close the GUI, it would have to go through

main_window::handle_octave_finished

and hence at least the first fprintf() output should appear.  I don't know about Mac OS X, though.  Perhaps stderr is directed somewhere other than the terminal window by default.

Dan Sebald <sebald>
Tue 26 Sep 2017 07:08:55 AM UTC, comment #7: 

I am very confused. I just compiled head with your patch. I see no output at all (with or without "--no-gui") but even more crazily: it does not freeze anymore. 

I will try to find out what is going on later today.

Thanks,
Sebastian

P.S.: yes, I am sure that I am looking at the correct version of octave :)

Sebastian <sschoeps>
Mon 25 Sep 2017 03:31:53 PM UTC, comment #6: 

We need to par down the amount of debug info to get an idea of what's causing the crash.  I'm attaching the same patch, but I put some prints within the code that should be easy to recognized even if they are mixed in with some system trace.  Could you run Octave from a command line and check if there is any meaningful output at exit?  First try:

./run-octave --no-gui

and see if there is an error.  (Even though the option says "no-gui", the GUI is actually launched, just not displayed.)  And then run

./run-octave &


(file #41891)

Dan Sebald <sebald>
Mon 25 Sep 2017 08:42:11 AM UTC, comment #5: 

Thanks Dan! I really appreciate this. The GUI is nicely working on macOS besides freezing on exit and some scaling issues of the plot engine on high-dpi screens. It seems rather minor stuff that stops mac users from using the GUI...

Sadly, your patch is not preventing that octave freezes. How can I provide helpful debug output?

Sebastian

Sebastian <sschoeps>
Sun 24 Sep 2017 09:09:21 PM UTC, comment #4: 

Let's try a simple little change (attached patch).  All this does is move the thread quit() to the GUI's main window which will allow also waiting on that quit.  It works here on Linux.  Let me know if it works on Mac OS X.  That's about all I have time to explore right now.

(file #41889)

Dan Sebald <sebald>
Sun 24 Sep 2017 08:26:36 PM UTC, comment #3: 

Folks, I think this is more of an Octave proper-Qt-programming issue than it is an OS X problem.  In particular, it is the proper sequence of shutting down threads.  I looked at the system complaints in the bug report

https://savannah.gnu.org/bugs/?50795

and although the dump is so voluminous to really not be helpful, I do see "pthread" and such in the list.

Let me try to illustrate what the issue probably is from looking at hunks of code.

The following is from mainwindow.cc:


  connect (m_interpreter, SIGNAL (octave_ready_signal (void)),
           m_doc_browser_window, SLOT (load_info_file (void)));

  connect (m_interpreter, SIGNAL (octave_finished_signal (int)),
           this, SLOT (handle_octave_finished (int)));

  connect (m_interpreter, SIGNAL (octave_finished_signal (int)),
           m_main_thread, SLOT (quit (void)));

  connect (m_main_thread, SIGNAL (finished (void)),
           m_main_thread, SLOT (deleteLater (void)));

  m_interpreter->moveToThread (m_main_thread);

  m_main_thread->start ();
}


What I wanted to explore is whether not starting the thread results in a clean thread.  But when I comment out the m_main_thread->start() line on Linux, the GUI hangs and only kill -9 will stop it.  Well, that's bad in the sense that Octave GUI should be much more graceful if the thread doesn't start properly.  It doesn't seem far-fetched that a thread doesn't start, so here is another thing to look at.  (My feeling is the whole startup/shutdown concept needs an overhaul.)

Now, shutdown.  octave_finished_signal (probably emitted when the interpreter is about to exit) is connected to "this" (i.e., the GUI main window) handle_octave_finished().  That's fine, it's just letting the GUI know it's done.

The m_main_thread finished() signal is connected to its deleteLater() slot.  This is fine too, as it has become a typical construct, at least in this prototypical example:

http://doc.qt.io/qt-5/qthread.html#details

Where I think the problem lies is this line:


  connect (m_interpreter, SIGNAL (octave_finished_signal (int)),
           m_main_thread, SLOT (quit (void)));


The m_interpreter is running in the thread, and it tells the thread to quit.  The Qt documentation makes no mention of such a construct, but I'm imagining that being an undefined sort of behavior.  Let's take a look at the prototype example of how quit is used:


    ~Controller() {
        workerThread.quit();
        workerThread.wait();
    }


Notice it is the Controller, the thing that launched the worker thread, that is issuing the quit.  The quit is not coming from within the thread.  But more than that, and probably the key issue, is that the Controller can also wait on the thread to finish.  If the GUI does not wait on the worker thread to finish, somewhere in the exit process, then there is a good chance this is problematic.  I suspect that is the source of failure for Mac OS X, i.e., that threads are structured differently internal to the OS.

Notice with the signal/slot construct of accessing quit(), there is no straightforward way of also doing a wait() somewhere.  This is why I'm saying the exit process needs to be reworked.  Add to that the GUI should also gracefully handle the thread not starting properly.  Also, the GUI should gracefully handle the interpreter crashing and the interpreter not responding at exit.  There is just a whole lot of work that needs to be done.

Dan Sebald <sebald>
Fri 27 Jan 2017 07:37:16 AM UTC, comment #2: 

Yes. Sadly, this is known. However, it might be that there was no bug report until now. This problem is there since we moved to qt5. I guess jpswensen is currently the only one who might be able to help here (see #49053).

Sebastian <sschoeps>
Fri 27 Jan 2017 01:48:42 AM UTC, comment #1: 

Adding sschoeps in cc. As far as I know it is known that the GUI can crash and freeze several different ways on macOS. If you can help debug and help make Octave more stable, please do so.

Mike Miller <mtmiller>
Group Member
Wed 11 Jan 2017 02:08:30 PM UTC, original submission:  

I have installed Octave version 4.2.0 via homebrew and created an Apple scriptfile with which I can start Octave Graphical User Interface.
But when I quit Octave GUI with simply closing it by clicking 'quit octave-gui' or typing 'quit' in command line, Octave shut down as it should but the window freezes and doesn't close until I force it to close with Apples Activity Manager.

Daniel <trez>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #47650:  octave-qt_alternate_quit_macos-apj-20191011-C.patch added by apjanke (2KiB - application/octet-stream - workaround special-cased to macOS, updated to apply to current default)
file #46530:  octave-qt_alternate_quit_macos-apj-20190313.patch added by apjanke (2KiB - application/octet-stream - version with the workaround special-cased to macOS)

 

Carbon-Copy List
  • -email is unavailable- added by seattle_2020 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by chfriedrich (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by sasaas (Posted a comment)
  • -email is unavailable- added by apjanke (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by henryiii (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by mschamschula (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by sschoeps (Posted a comment)
  • -email is unavailable- added by mtmiller
  • -email is unavailable- added by trez (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 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-07 mmuetzel StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2020-05-21 siko1056 DependenciesRemoved dependency to bugs #58409 -
    2020-05-21 siko1056 Dependencies- bugs #58409 is dependent
    2020-05-21 siko1056 DependenciesRemoved dependency to bugs #58409 -
    2020-05-21 siko1056 Dependencies- Depends on bugs #58409
    2019-10-11 rik5 Priority5 - Normal 3 - Low
    2019-10-11 apjanke Attached File- Added octave-qt_alternate_quit_macos-apj-20191011-C.patch, #47650
    2019-10-11 apjanke Attached File- Added octave-qt_wait_on_worker_thread-apj2019Oct11.patch, #47649
    2019-03-13 apjanke Attached File- Added octave-qt_alternate_quit_macos-apj-20190313.patch, #46530
    2019-03-13 apjanke Attached File- Added octave-6.0.0-hang-on-close-truncated.spindump.zip, #46521
    2018-11-08 mtmiller Carbon-CopyRemoved 80942 -
    2018-11-08 bpabbott Attached File- Added octave-qt_wait_on_worker_thread-djs2018Oct19.patch, #45382
    2018-11-08 bpabbott Release4.2.0 dev
    2018-04-05 bpabbott Attached File- Added octave-qt_wait_on_worker_thread-djs2018Apr04.patch, #43807
    2018-04-04 bpabbott Attached File- Added octave-qt_wait_on_worker_thread-djs2018Apr02.patch, #43793
    2018-01-11 bpabbott Attached File- Added octave-qt_wait_on_worker_thread-djs2017sep25.patch, #42886
    2017-11-20 sebald Attached File- Added octave-qt_wait_on_thread-djs2017nov21.patch, #42446
    2017-11-20 sebald Attached File- Added octave-qt_wait_on_thread-djs2017nov20.patch, #42445
    2017-09-25 sebald Attached File- Added octave-qt_wait_on_worker_thread-DEBUG1-djs2017sep25.patch, #41891
    2017-09-24 sebald Attached File- Added octave-qt_wait_on_worker_thread-djs2017sep24.patch, #41889
    2017-06-12 mtmiller Dependencies- bugs #51216 is dependent
    2017-04-27 mtmiller Dependencies- bugs #50795 is dependent
    2017-01-27 mtmiller StatusNone Need Info
        Carbon-Copy- Added sschoeps

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code