bugGNU Octave - Bugs: bug #44751, Failure to exit when running...

 
 

bug #44751: Failure to exit when running Octave in --no-gui mode

Submitted by:  Guillaume <gyom>
Submitted on:  Mon 06 Apr 2015 06:34:03 PM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Guillaume Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

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)

Sat 25 Apr 2015 12:37:07 PM UTC, comment #53: 

I applied your patch and it still works fine, ie it exits properly.
I'll add further comments about Ctrl+C in bug #44912.

Guillaume <gyom>
Sat 25 Apr 2015 05:11:31 AM UTC, comment #52: 

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)

Dan Sebald <sebald>
Sat 18 Apr 2015 09:44:33 PM UTC, comment #51: 

Many thanks for sorting this one out!

Guillaume <gyom>
Sat 18 Apr 2015 09:07:01 PM UTC, comment #50: 

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

Rik <rik5>
Project Administrator
Sat 18 Apr 2015 05:52:47 PM UTC, comment #49: 

Yes, that should cover everything...

Thanks for doing all the trial-and-error tests on openSUSE.

Dan Sebald <sebald>
Sat 18 Apr 2015 02:36:06 PM UTC, comment #48: 

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

Rik <rik5>
Project Administrator
Sat 18 Apr 2015 11:39:29 AM UTC, comment #47: 

Dan, many thanks for all the time you invested on this.

With your last changeset, it works well and I don't see any problem with the other dialog boxes (eg demo errordlg works fine).

Thanks!

Guillaume <gyom>
Sat 18 Apr 2015 03:52:31 AM UTC, comment #46: 

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)

Dan Sebald <sebald>
Fri 17 Apr 2015 02:40:24 PM UTC, comment #45: 

Dan, I also tried with patch 33690 and replacing 3000 by 1500 and... it works as well!

./run-octave --no-gui -f -q
Qt Link Thread Before Move: 29826128
Qt Link Thread After Move: 32416144
JUST CONNECTED confirm_shutdown_signal

>> exit
LOCKING THE MUTEX
_shutdown_confirm_result BEFORE EMIT: -1
EMITTING SIGNAL
SLOT IS CALLED: confirm_shutdown_octave
closenow = 1
_shutdown_confirm_result AFTER EMIT: -1
GOING INTO WAIT STATE, SIMULTANEOUS UNLOCK MUTEX
Attempting to Awake process...
COMING OUT OF WAIT STATE, shutdown = 1

I don't observe a 1.5s delay though.

But it seems that you are right and the problem is due to an overflow in the Qt library, version 4.8.6.

Guillaume <gyom>
Fri 17 Apr 2015 10:03:34 AM UTC, comment #44: 

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.

Guillaume <gyom>
Fri 17 Apr 2015 06:56:39 AM UTC, comment #43: 

There is this bug report

https://bugreports.qt.io/browse/QTBUG-24795

that sounds like it might relate to the tryLock(3000) not waiting.

Version 4.8.6 of the code is here:

https://qt.gitorious.org/qt/qt/source/8ab1ad64620ff9d0453a326010d161ea68a63a2f:src/corelib/thread/qmutex_unix.cpp

If you have 64bit system (i.e., /usr/lib64), maybe this bug doesn't apply.  If you are interested, you could try this patch

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

again but change

+  if (! _octave_qt_link->mutex.tryLock (3000))

to

+  if (! _octave_qt_link->mutex.tryLock (1500))

Maybe you will see a 1.5 second delay and proper exit behavior.

(If using just mutex.lock() works, we might go with that in any case and forgo the timeout.)

Dan Sebald <sebald>
Thu 16 Apr 2015 07:26:42 PM UTC, comment #42: 

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)

Dan Sebald <sebald>
Thu 16 Apr 2015 06:19:17 PM UTC, comment #41: 

It did exit indeed :-) but there was no delay.

./run-octave --no-gui -f -q
Qt Link Thread Before Move: 33762384
Qt Link Thread After Move: 36349040
JUST CONNECTED confirm_shutdown_signal

>> exit
octave_qt_link::do_confirm_shutdown thread affinity: 36349040
LOCKING THE MUTEX
_shutdown_confirm_result BEFORE EMIT: -1
EMITTING SIGNAL
SLOT IS CALLED: confirm_shutdown_octave
main_window::confirm_shutdown_octave thread affinity: 33762384
closenow = 1
_shutdown_confirm_result AFTER EMIT: -1
GOING INTO WAIT STATE, SIMULTANEOUS UNLOCK MUTEX
WAS THERE A 3 SECOND BEFORE THIS LINE APPEARED????
Couldn't get lock, bad handshake
COMING OUT OF WAIT STATE, shutdown = 1

Guillaume <gyom>
Thu 16 Apr 2015 06:12:03 PM UTC, comment #40: 

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)

Dan Sebald <sebald>
Thu 16 Apr 2015 05:07:10 PM UTC, comment #39: 

./run-octave --no-gui -f -q
Qt Link Thread Before Move: 26958928
Qt Link Thread After Move: 29545168
JUST CONNECTED confirm_shutdown_signal

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

Guillaume <gyom>
Thu 16 Apr 2015 05:03:39 PM UTC, comment #38: 

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)

Dan Sebald <sebald>
Thu 16 Apr 2015 03:14:21 PM UTC, comment #37: 

Thanks Dan, here it is:

./run-octave --no-gui -f -q
Qt Link Thread Before Move: 18492496
Qt Link Thread After Move: 21079152

POINTER: _octave_qt_link = 20977200
Qt Link Thread: 21079152
Main Window Thread: 18492496
JUST CONNECTED confirm_shutdown_signal

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

Guillaume <gyom>
Thu 16 Apr 2015 07:52:03 AM UTC, comment #36: 

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

(file #33685)

Dan Sebald <sebald>
Mon 13 Apr 2015 04:51:57 PM UTC, comment #35: 

Just in case someone wants to reproduce the problem locally, I just checked that it takes about 1h15 to create a VM and build Octave on it (most of the time just waiting installation/compilation to go through).

  • Create an openSUSE 13.2 Virtual Machine:

  http://software.opensuse.org/132/en
  (I used 1 CPU, 5GB RAM, 20GB partition)
  (using defaults, just check "add Online Repositories before install", "Update repository (Non OSS)", "Main repository (Sources)", "Main Update repository")

  • Install all relevant packages:

zypper source-install -d octave
zypper install mercurial libtool rsvg-view

  • Clone, configure and compile Octave:

hg clone http://www.octave.org/hg/octave
cd octave
./bootstrap
mkdir .build
cd .build
../configure
make
./run-octave --no-gui

Guillaume <gyom>
Fri 10 Apr 2015 06:21:27 PM UTC, comment #34: 

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...

Dan Sebald <sebald>
Fri 10 Apr 2015 05:17:17 PM UTC, comment #33: 

And I get this:

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

POINTER: _octave_qt_link = 23606832
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

Something that might be interesting, or not, is what I observed when using the GUI but having a non-saved file in the editor so that I am asked whether I want to save it before exiting; I press cancel, save it/close it and type exit again: I then get block in the same way than with --no-gui:

>> exit
LOCKING THE MUTEX
EMITTING SIGNAL
GOING INTO WAIT STATE, SIMULTANEOUS UNLOCK MUTEX
SLOT IS CALLED: confirm_shutdown_octave   <- Cancel then close/save file ->
closenow = 0
Attempting to Awake process...
COMING OUT OF WAIT STATE, shutdown = 0
>> exit
LOCKING THE MUTEX

Guillaume <gyom>
Fri 10 Apr 2015 04:44:54 PM UTC, comment #32: 

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

(file #33631)

Dan Sebald <sebald>
Fri 10 Apr 2015 10:06:44 AM UTC, comment #31: 

Thanks for the update, latest build with your patch gives:

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

POINTER: _octave_qt_link = 32073040
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

Guillaume <gyom>
Fri 10 Apr 2015 04:41:06 AM UTC, comment #30: 

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)

Dan Sebald <sebald>
Thu 09 Apr 2015 10:54:31 PM UTC, comment #29: 

@sebald: no delay between these two lines, they appear 'simultaneously'.

@jwe: sorry, I should have mentioned that to start with.

>> qmake --version
QMake version 2.01a
Using Qt version 4.8.6 in /usr/lib64

>> pkg-config --modversion QtCore
4.8.6

[Qt3: 3.3.8c, Qt4: 4.8.6, Qt5: 5.4.1]

Guillaume <gyom>
Thu 09 Apr 2015 10:44:01 PM UTC, comment #28: 

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.

Dan Sebald <sebald>
Thu 09 Apr 2015 10:36:18 PM UTC, comment #27: 

What version of Qt does Open SuSE 13.2 have?

John W. Eaton <jwe>
Project Administrator
Thu 09 Apr 2015 10:28:29 PM UTC, comment #26: 

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

Guillaume <gyom>
Thu 09 Apr 2015 10:20:10 PM UTC, comment #25: 

All right, no change.  How about the attached diff file?  It has an added tryLock() to the slot code.

(file #33621)

Dan Sebald <sebald>
Thu 09 Apr 2015 09:49:41 PM UTC, comment #24: 

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

Guillaume <gyom>
Thu 09 Apr 2015 08:51:11 PM UTC, comment #23: 

Out of curiosity, could you apply the attach diff file (from a clean repository) and report back the printout?  I've added a line that will lock the Mutex before emitting the signal.

(file #33619)

Dan Sebald <sebald>
Thu 09 Apr 2015 07:43:19 PM UTC, comment #22: 

[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.

Dan Sebald <sebald>
Thu 09 Apr 2015 07:20:52 PM UTC, comment #21: 

This time I get:

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

POINTER: _octave_qt_link = 18650240
JUST CONNECTED confirm_shutdown_signal

>> exit
SLOT IS CALLED: confirm_shutdown_octave
closenow = 40
Attempting to Awake process...
GOING INTO WAIT STATE

Guillaume <gyom>
Thu 09 Apr 2015 07:12:41 PM UTC, comment #20: 

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)

Dan Sebald <sebald>
Thu 09 Apr 2015 06:59:39 PM UTC, comment #19: 

Yes, please keep this on the bug tracker. I'm seeing the same behaviour (exit blocks when running with --no-gui) on Debian wheezy.

Andreas Weber <andy1978>
Project Member
Thu 09 Apr 2015 06:54:58 PM UTC, comment #18: 

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

John W. Eaton <jwe>
Project Administrator
Thu 09 Apr 2015 06:46:30 PM UTC, comment #17: 

Yes, all plots and figures work great with the --no-gui option; the problem is only at exit.

After applying your last patch, it's getting interesting:

./run-octave -f --no-gui
>> exit
GOING INTO WAIT STATE

ie the second line is not displayed.

We can go off the list if you find it more convenient.

Guillaume <gyom>
Thu 09 Apr 2015 06:07:26 PM UTC, comment #16: 

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)

Dan Sebald <sebald>
Thu 09 Apr 2015 10:45:18 AM UTC, comment #15: 

Dan, many thanks for looking into this.

I applied your patch (thanks for the detailed instructions), unfortunately the problem is still there.

Guillaume <gyom>
Thu 09 Apr 2015 03:23:22 AM UTC, comment #14: 

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.

Dan Sebald <sebald>
Wed 08 Apr 2015 06:16:04 PM UTC, comment #13: 

The code for the octave-link layer is in libinterp/corefcn/octave-link.[cc|h].

The code for the link to Qt is in libgui/src/octave-qt-link.[cc|h].

Dan Sebald might know where to begin hunting.

Rik <rik5>
Project Administrator
Wed 08 Apr 2015 04:26:53 PM UTC, comment #12: 

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.

Guillaume <gyom>
Wed 08 Apr 2015 03:42:37 PM UTC, comment #11: 

I checked in a fix for bug #44759.  I changed a few other instances where Octave might not unlock the graphics handle, but there still might be others.

Guillaume, Can you try to reproduce the exit problem with a version >= 20047:0f1a722133f4.

Rik <rik5>
Project Administrator
Wed 08 Apr 2015 11:44:22 AM UTC, comment #10: 

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.

Guillaume <gyom>
Tue 07 Apr 2015 07:29:14 PM UTC, comment #9: 

I answered my own question, part 2 in comment #8.  There are several other instances where error() statements result in the figure remaining locked.  I'll fix those, but having a way to override gh_manager for exit is still desirable.

Rik <rik5>
Project Administrator
Tue 07 Apr 2015 07:10:16 PM UTC, comment #8: 

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.

Rik <rik5>
Project Administrator
Tue 07 Apr 2015 04:49:32 PM UTC, comment #7: 

I have observed this problem as well, but had not reported it because it is intermittent on my system and I haven't found the triggering condition for it.  If it has been fixed in the past week that is good news.  I will continue to monitor my system.

Rik <rik5>
Project Administrator
Tue 07 Apr 2015 11:18:56 AM UTC, comment #6: 

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).

Guillaume <gyom>
Tue 07 Apr 2015 07:02:50 AM UTC, comment #5: 

It freezes even when the first command is exit(). See this as well:

~/octave/.build> ./run-octave --no-gui --eval exit
^C^C^Cpanic: Interrupt -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete

~/octave/.build>

Guillaume <gyom>
Tue 07 Apr 2015 02:12:27 AM UTC, comment #4: 

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

Mike Miller <mtmiller>
Project Administrator
Mon 06 Apr 2015 09:44:35 PM UTC, comment #3: 

Thanks for your detailed response @sebald. I am using the latest development version.

It might well be a duplicate of bug #44116 - I'll check whether I still observe the problem once your patch has been committed.

Guillaume <gyom>
Mon 06 Apr 2015 08:44:33 PM UTC, comment #2: 

This does not happen with Fedora systems that I
use.

Michael Godfrey <godfrey>
Project Member
Mon 06 Apr 2015 07:08:47 PM UTC, comment #1: 

When --no-gui is used, the link between Qt and Octave still exists.  So in some sense the --no-gui and "with GUI" mode are similar.  --no-gui-libs is different (no link established).

When there is a link established, Octave core "exit" will inquire with the link (what would normally be the GUI) whether it is OK to shutdown.  That step is typically used for closing/saving all editor windows and whatnot.

There needs to be a connection between this signal and some slot.  The latest development version might also handle this by creating a main_window, but not displaying.  There is a patch here:

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

that establishes that connection even in the case of main_window not constructed.

Are you using the very latest development version?  Or something that might be a week old or older?

For reference, there is also a patch in the works to address a related problem, one of forcing a shutdown when Octave core appears busy:

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

but it's best to address that after the --no-gui issues are worked out.

Dan Sebald <sebald>
Mon 06 Apr 2015 06:34:03 PM UTC, original submission:  

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.

Guillaume <gyom>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #33706:  octave-shutdown_lock_mutex-djs2015apr16.patch added by sebald (13KiB - application/octet-stream)
file #33694:  use_lock-2015apr16.diff added by sebald (3KiB - application/octet-stream)
file #33692:  affinity_always_confirm-2015apr16.diff added by sebald (4KiB - application/octet-stream)
file #33690:  check_before_after_emit-2015apr16.diff added by sebald (3KiB - application/octet-stream)
file #33685:  display_thread_pointer-2015apr16.diff added by sebald (3KiB - application/octet-stream)
file #33631:  force_queued_2015apr10.diff added by sebald (2KiB - application/octet-stream)
file #33625:  move_qtlink_thread-2015apr09.diff added by sebald (3KiB - application/octet-stream)
file #33621:  mutex_lock_slot_trylock-2015apr09.diff added by sebald (2KiB - application/octet-stream)
file #33619:  add_mutex_lock-2015apr09.diff added by sebald (2KiB - application/octet-stream)
file #33618:  show_several_vars_2015apr09.diff added by sebald (2KiB - application/octet-stream)
file #33616:  show_shutdown_result-2015apr09.diff added by sebald (559B - application/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by andy1978 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by gyom (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.

     

     

     

    Follow 18 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-04-25 rik5 Dependencies- => bugs #44912 is dependent
    2015-04-25 sebald Attached File- => Added octave-octave_qt_link_thread_affinity-djs2015apr24.patch, #33781
    2015-04-18 rik5 StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2015-04-18 sebald Attached File- => Added octave-shutdown_lock_mutex-djs2015apr16.patch, #33706
    2015-04-16 sebald Attached File- => Added use_lock-2015apr16.diff, #33694
    2015-04-16 sebald Attached File- => Added affinity_always_confirm-2015apr16.diff, #33692
    2015-04-16 sebald Attached File- => Added check_before_after_emit-2015apr16.diff, #33690
    2015-04-16 sebald Attached File- => Added display_thread_pointer-2015apr16.diff, #33685
    2015-04-10 sebald Attached File- => Added force_queued_2015apr10.diff, #33631
    2015-04-10 sebald Attached File- => Added move_qtlink_thread-2015apr09.diff, #33625
    2015-04-09 sebald Attached File- => Added mutex_lock_slot_trylock-2015apr09.diff, #33621
    2015-04-09 sebald Attached File- => Added add_mutex_lock-2015apr09.diff, #33619
    2015-04-09 sebald Attached File- => Added show_several_vars_2015apr09.diff, #33618
    2015-04-09 sebald Attached File- => Added show_shutdown_result-2015apr09.diff, #33616
    2015-04-07 rik5 StatusWorks For Me => Confirmed
    2015-04-07 mtmiller CategoryNone => Interpreter
        StatusNone => Works For Me

    Back to the top


    Powered by Savane 3.5