The patch that was applied was merely to fix seg faults sometimes appearing at exit because some GUI objects were left active and without a parent.

You may be thinking of the patch here:

https://savannah.gnu.org/bugs/?func=detailitem&item_id=44485

the intention of which was to allow the GUI to exit even though the core is active or stuck.  I felt like I came close to solving that one, but at some point it started to feel too convoluted so I cried uncle, I guess.

The strategy I think is the right one.  If the user selects "exit" and the core is busy or stuck the GUI does not get an acknowledgement so sits silent.  So what I had done was start a Qt timer at the time of exit and if after half a second or so with no acknowledgement the timer expires and causes a dialog box to appear asking if exit should be forced.  (We don't want to toss someone's possibly long-running job just because they accidentally select close of the GUI window or type cntrl-Q when trying to close some other application's window.)  But that's not all of it.  Say the dialog box is displayed and THEN the acknowledgement comes.  Well, then we have to force that dialog closed even though the user hasn't selected anything so that the GUI can continue on and exit.  Oh, and the other thing is that one has to create some variable to block MULTIPLE exits with cntrl-Q or whatnot so that the dialog box doesn't appear more than once.

It just felt like it was getting to be too complex such that there might be a better way.  I could get active on that

https://savannah.gnu.org/bugs/?func=detailitem&item_id=44485

patch again if something is needed for the next release.

I updated and pushed this changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/6e9f5408c0db

Good suggestion, Philip.

Once I've finished a pass of triage, I'll check and polish this and all other supplied patches to the best of my ability, and mark that on the Wiki.

I'll also select some of my patches that aren't in one of Rik's selected categories but which I think should go into 4.2, and see if someone is willing to review and commit them :)

Adding Rik to cc list.

Lachlan why don't you polish the patch up to standards, and I'll test, and then we bug the core devs again? 
I normally don't push csets containing C/C++ code.

BTW, noting I tested this over a year ago.

Good.  Thanks for testing.

Works fine on Linux (Mageia-4 64bit). Exits gracefully:

When doing:
[V, D] = eigs (rand (10000));
and then
File | Exit
after ~ 3 seconds I see "exit" flashing by in the terminal and Octave closes.

Cross-building for Windows now in background (while I help my daughter with her homework) - maybe tonight I can report on the Windows side.

In attempting to use the qApp aboutToQuit signal to save object settings I continually experienced a SEGV (11) segment fault at exit.  (This fact is probably led to the approach whereby the worker thread singleton-cleanup mechanism is used to clean up some GUI object.  That holds off deletion until the very last step.)  I eventually tracked down some bugs that are the source of segfault:

1) terminal_dock_widget::~terminal_dock_widget destructor is not deleting the dynamically-created QTerminal pointed to via 'terminal'.

2) QUnixTerminalImpl::~QUnixTerminalImpl destructor is not deleting the dynamically created TerminalModel (m_terminal), KPty (m_kpty), and TerminalView (m_terminalView).

The reason this causes a segmentation fault is that some of the objects left undeleted are widgets that remain active in the event processing of the GUI thread.  But at deletion during exit, their parents are gone and they may continue to access things such as resource_manager and shortcut_manager.  Objects have to delete the dynamic memory/objects they utilize, or hand those objects over to a container class such as the layout classes.

I will submit a patch shortly that includes the bug fixes in a larger reworking of the exit and cleanup code.