Could those observing this problem originally on an openSUSE system try the attached patch and confirm that the problem is not re-introduced?  We've found that signals are not handled properly with the octave_qt_link thread affinity not in the GUI thread.  Thanks.


(file #33781)

Pushed cset here (http://hg.savannah.gnu.org/hgweb/octave/rev/89d843d6de14).  Marking bug fixed and closing report.

@Dan: Is file #33706 the final version that you want pushed to Mercurial or do you have any other changes to make?

Great!  This output:

MAIN> Waiting for link mutex to free...
LINK> _shutdown_confirm_result AFTER EMIT: -1
LINK> GOING INTO WAIT STATE, SIMULTANEOUS UNLOCK MUTEX
MAIN> closenow = 1
MAIN> Attempting to Awake process...

is what I was hoping to see.  The main thread is getting ahead of the interpreter/link thread.  The main thread waits, the link goes to sleep and frees the mutex.  Then main thread gets the lock and continues.

"I wonder if it might be linked to the fact that I am doing the tests from within a VM that has been attributed a single core."

That's a possibility--if it is the case that because of the one core there is a very short interval that is spent in one thread before switching to the other.

"I also tried with patch 33690 and replacing 3000 by 1500 and... it works as well! I don't observe a 1.5s delay though."

Ah, you're right.  There's no discernible delay because the main thread gets the mutex lock after waiting just a few milliseconds.  But it does wait properly when 1500 is specified, so that's good.  It's nice to have a full understanding of that issue.

Well, I think we'll try setting up the link/main connection with a mutex and lock() rather than tryLock(1500) and see how that goes.  Yes, we could print out some kind of failure if the lock attempt fails after 1.5 seconds--it's informative, I suppose, but dropping out of a comm protocol can put a system in an odd state where things might not work right.  Shouldn't be any problems, if there is then we'll address it.

I'm attaching a first proposal for a changeset.  You may treat it just like a patch file and do not have to import it like a changeset.  Please try it out.  I've also added similar handshaking for all the cross-thread transfers, those being mainly the dialog boxes.  Those worked for you, but for reasons of the inherent delay it takes a user to select an option.  The modifications should now be consistent with what we just figured out.  Also test things like "demo errordlg" to confirm that still works properly.

(file #33706)

Many thanks Dan, seems like you found a solution (with patch 33694)!

./run-octave --no-gui -f -q
LINK> Qt Link Thread Before Move: 35884112
LINK> Qt Link Thread After Move: 38470768
MAIN> JUST CONNECTED confirm_shutdown_signal

>> exit
LINK> octave_qt_link::do_confirm_shutdown thread affinity: 38470768
LINK> LOCKING THE MUTEX
LINK> _shutdown_confirm_result BEFORE EMIT: -1
LINK> EMITTING SIGNAL
MAIN> SLOT IS CALLED: confirm_shutdown_octave
MAIN> main_window::confirm_shutdown_octave thread affinity: 35884112
MAIN> Waiting for link mutex to free...
LINK> _shutdown_confirm_result AFTER EMIT: -1
LINK> GOING INTO WAIT STATE, SIMULTANEOUS UNLOCK MUTEX
MAIN> closenow = 1
MAIN> Attempting to Awake process...
LINK> COMING OUT OF WAIT STATE, shutdown = 1

Given your description, I wonder if it might be linked to the fact that I am doing the tests from within a VM that has been attributed a single core. It would also be useful to know if it fixes the problem observed by @andy1978 on Debian Wheezy.
I'll try your last suggestion later on.

Attached is another patch file, this time we'll use "lock" instead of "tryLock".  "lock" returns a void because it blocks until it gets a lock, i.e., completes the lock or never returns.

That lack of a 3 second wait is confounding.  tryLock(3000) is supposed to wait three seconds before declaring a fail to lock.  Not fail immediately.

I'm guessing the original source of error here was a timing issue.  The fact that _shutdown_confirm_result comes back from the signal emit unchanged indicates the signal was, in fact, queued, not direct.  That agrees with the thread affinity.  On the other hand, the printf() statements are somewhat out of order from what they should appear if operating correctly.  It seems that your system behaves slightly different than mine in the sense the threads might be either operating on different CPUs or the CPU resource is shared between threads in smaller time intervals.  In other words, the main_window thread is getting ahead of the qt_link thread.  That's not a problem at all.  If the attached patch works for you, we have a solution...

(file #33694)

Here's another patch that should likely exit, but I'm not sure if that's good or bad (i.e., it exits, but not in the proper way).  Also, the thread affinity of the signal and slot will be printed.  And I've put a message

WAS THERE A 3 SECOND BEFORE THIS LINE APPEARED????

in the code.  If you see that message, let me know if there actually was a three second delay before it appeared after the line previous ("closenow = 1").  Thanks.


(file #33692)

Thanks.  Well, the threading looks to be operating in a sane fashion.  Here's another diff file that should discern if the signal is direct or queued.

(file #33690)

I'm attaching another diff file with some printout of the thread pointer info.  Please let me know what you see.

(file #33685)

Good observation, but that's nothing really.  I just forgot to unlock the mutex after coming out of the wait state.  I unlocked the mutex here and tested--the editor window Save/Cancel works fine here.

For some unknown reason, the shutdown confirmation signal doesn't appear to be queued when in non-GUI mode on your system--even when specifically indicating Qt::QueuedConnection.  Your second printout shows the slot processed after the wait state, which is as designed.

I'll be busy the next couple days, but I'll keep thinking...

OK, another one.  This time force the connection to be queued (forgot about that option).

(file #33631)

Here is another diff file for you to try.  All I've added over the previous diff is a

  // Move this link object in the same thread as the interpreter.
  moveToThread (main_thread);

[Note: "main_thread" here does not mean the main program thread.  A better name might have been "interpreter_thread".]

This is meant to test the theory that signals are direct rather than queued because the Qt link is constructed under the main program thread.

The main_window needs to be in the main program thread, and that is constructed in octave-gui.cc.  The interpreter is in a worker thread created by the Qt link.  However, in the repository the Qt link is constructed by main_window (main thread).  In the patch here:

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

the Qt link is constructed prior to the main_window, but that still is instantiated by the main thread in octave-gui.cc.

So, let's see if it is possible to explicitly move the Qt link to the other thread and thereby make the signals it emits queued.

(file #33625)

Actually, that's different.  "Attempting to Awake process..." isn't showing anymore.  No longer is the slot attempting to wake the thread because it can't get a lock on the mutex after three seconds.  I would guess that you are seeing a three second delay now between

closenow = 1

and

GOING INTO WAIT STATE, SIMULTANEOUS UNLOCK MUTEX

That suggests to me that the emitted signal isn't queued across some thread.  Instead it is linear: the mutex is locked, then tryLock() is done but a lock can't be obtained so after three seconds the function returns to that point after "emit" which goes into a wait state.

OK, I have enough info to work with now.  Thanks.

Same apparently:

./run-octave --no-gui -f -q

POINTER: _octave_qt_link = 29230480
JUST CONNECTED confirm_shutdown_signal

>> exit
LOCKING THE MUTEX
EMITTING SIGNAL
SLOT IS CALLED: confirm_shutdown_octave
closenow = 1
GOING INTO WAIT STATE, SIMULTANEOUS UNLOCK MUTEX

Here it is:

./run-octave --no-gui -f -q

POINTER: _octave_qt_link = 21005552
JUST CONNECTED confirm_shutdown_signal

>> exit
LOCKING THE MUTEX
EMITTING SIGNAL
SLOT IS CALLED: confirm_shutdown_octave
closenow = 1
Attempting to Awake process...
GOING INTO WAIT STATE, SIMULTANEOUS UNLOCK MUTEX

[The "closenow = 40" is a mistake, I forgot a printf argument, but it doesn't matter.]

That's odd.  The peculiar thing is that the confirm_shutdown_octave slot is being called prior to the wait state on your system (or version of Qt).  In other words, the "awake" is being done before the Octave core process goes to "sleep".  That shouldn't happen across threads, as the

  emit confirm_shutdown_signal ();

should be queued and not run.

I suppose there is a simple solution, which is to first put a bogus value into what is to be returned and if after the emit is done the return value is no longer bogus it means the slot was already run so no need to go into the wait state.

But let me search around first as to why this signal hasn't been queued--whether it has something to do with the construction of link and main_window objects, or perhaps a change or optimization in the version of Qt on openSUSE 13.2 and Debian wheezy.

I'll send a bug fix patch later this afternoon or evening.

OK, thanks G.  Let's print out a few more details to see if the connection is being completed and whether the slot is actually being called.  Revert to a fresh repository and patch the diff file...


(file #33618)

I think it would be more helpful for people who follow if you continue posting comments on the bug tracker.

OK.  Since you are the only one seeing this problem now that R has moved some similar problems out of the picture, I'm going to send some short patches to attempt to debug this.  We can maybe move this off the list, unless you want to stay with the list.

Try the attached patch, and tell me what you see.  I'm seeing something like:

./run-octave -f --no-gui

>> exit

GOING INTO WAIT STATE
COMING OUT OF WAIT STATE, shutdown = 1

Also, just to confirm: when you are running with the --no-gui option in openSUSE 13.2, are you able to create plots/figures?  How about dialog boxes like

errordlg("not right")

?  Do these seem to function like they should?


(file #33616)

Just to do something easy first to see if it solves the problem, give this changeset a try.  (Actually it is two changesets back to back.)

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

But don't apply it as a changeset.  Instead, use the system's patch command to make changes.

With a repository with no modifications, i.e., type "hg diff" and there are no diff hunks, apply the patches as follows:

1) Copy the above file into the base Octave directory.  (I.e., where .hg directory resides.)

2) Type "patch -p1 < octave-qt_without_gui-djs2015apr05.patch" and both patches should apply cleanly.  If not, then let me know.  If you want to first test what will happen without actually patching, try "patch -p1 --dry-run < octav-qt_without_gui-djs2015apr05.patch".

3) Recompile Octave.

Now test whether that fixed the exit problem.  It might not.  If not, that helps identify what the problem is in any case.

4) If you type "hg diff" you'll see the changes that were applied by the patch.  But you can get back to a clean repository easily with "hg revert --all", and then recompile.

Just compiled the latest version and I'm afraid the problem is still there, with 100% reproducibility.

I was trying to look at the code but didn't know where to start: is it in libinterp/corefcn/toplev.cc? I was looking at clean_up_and_exit() but it seems that the problem occurs before this point.

I confirm it works fine when using "run-octave -f --no-gui-libs".

Otherwise, when using "./run-octave -f --no-gui", I don't even need to open a figure or type any command to observe the issue at exit.

Sample code that repeatedly fails for me

./run-octave -f --no-gui
figure
drawnow XXXX
exit

The problem is outlined in bug #44759 for a special case of drawnow.  What is happening is that the gh_manager is becoming locked, and due to an error or other unusual code path, is not getting unlocked.  When Octave goes to exit it checks with the octave_link to see whether there are windows outstanding and a deadlock situation arises.

This isn't a problem for me if I use run-octave -f --no-gui-libs, implying that the Qt libraries and octave_link need to be present.

While bug #44759 can easily be fixed.  It would probably be worth doing two things.  First, providing a way for octave_link to recognize that exit was called and override and locks in gh_manager.  Second, review the code which locks and unlocks graphic figures to determine if there are other code paths which can fail to unlock a figure after use.

Just to add that I don't observe the error with latest development version compiled on an older openSUSE 10.3 (with --without-opengl --without-framework-opengl --disable-gui flags).

I am unable to reproduce this as well. Any particular sequence of Octave commands to cause this to happen?

This does not happen with Fedora systems that I
use.

While it works great with the GUI, Octave systematically freezes when exiting from a non-graphical interface:

~/octave/.build> ./run-octave --no-gui
GNU Octave, version 4.0.0-rc2
Copyright (C) 2015 John W. Eaton and others.
[...]

>> exit
^C^CPress Control-C again to abort.
^Cpanic: Interrupt -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete

~/octave/.build>

I'm using openSUSE 13.2.