bugGNU Octave - Bugs: bug #37672, CTRL+C interrupt processing causes...

 
 

bug #37672: CTRL+C interrupt processing causes segfaults

Submitter:  Thorsten Liebig <thorsten>
Submitted:  Tue 06 Nov 2012 09:03:06 AM UTC
   
 
Category:  GUI Severity:  5 - Blocker
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 08 Mar 2018 07:50:56 PM UTC, comment #75: 

I think it can be closed.

Rik <rik5>
Group administrator
Thu 08 Mar 2018 07:07:20 PM UTC, comment #74: 

Is it OK to close this report?  I think the Ctrl-C crash related to threads is fixed now (see bug #52757).  Now we have a single thread waiting for interrupt signals so it should not be possible for a random OpenBLAS thread to catch an interrupt signal.

John W. Eaton <jwe>
Group administrator
Tue 12 Jul 2016 05:12:56 AM UTC, comment #73: 

A patch that seems to address this has been posted at bug #47400.  Please provide feedback.

Lachlan Andrew <lachlan>
Tue 28 Jun 2016 01:04:26 AM UTC, comment #72: 

If the workaround is to close OpenBlas threads, will OpenBlas restart them?

Lachlan Andrew <lachlan>
Sat 11 Jun 2016 08:32:59 PM UTC, comment #71: 

I get something similar with gdb which shows that the call to


system ("", 1)


really just succeeds in closing down the extra OpenBlas threads which is why subsequent Ctrl+C keystrokes work.

The debug session is below.


>> pause (2)
^C
Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7fffdf51f700 (LWP 19368)]
pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
185     ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or directory.
(gdb) info threads
  Id   Target Id         Frame
  5    Thread 0x7fffd49f8700 (LWP 19371) "QThread" 0x00007ffff440253d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
  4    Thread 0x7fffda51d700 (LWP 19370) "lt-octave-gui" pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  3    Thread 0x7fffded1e700 (LWP 19369) "lt-octave-gui" pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
* 2    Thread 0x7fffdf51f700 (LWP 19368) "lt-octave-gui" pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  1    Thread 0x7ffff7f91840 (LWP 19293) "lt-octave-gui" 0x00007ffff4123b1d in poll () at ../sysdeps/unix/syscall-template.S:81
(gdb) list
180     in ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S
(gdb) c
Continuing.
>>
>> system ("", 1)
ans = 0
>> pause (2)
^C
Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7fffd49f8700 (LWP 19371)]
0x00007ffff440253d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
81      ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) info threads
  Id   Target Id         Frame
* 5    Thread 0x7fffd49f8700 (LWP 19371) "QThread" 0x00007ffff440253d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
  1    Thread 0x7ffff7f91840 (LWP 19293) "lt-octave-gui" 0x00007ffff4123b1d in poll () at ../sysdeps/unix/syscall-template.S:81




Rik <rik5>
Group administrator
Fri 10 Jun 2016 06:32:58 PM UTC, comment #70: 

That's pretty interesting.

Here's what the thread state looks like with ./run-octave -qfH --no-gui


(gdb) info threads
  Id   Target Id         Frame
  9    Thread 0x7f90b6d75700 (LWP 20771) "lt-octave-gui" pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  8    Thread 0x7f90b6574700 (LWP 20772) "lt-octave-gui" pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  7    Thread 0x7f90b5d73700 (LWP 20773) "lt-octave-gui" pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  6    Thread 0x7f90b1572700 (LWP 20774) "lt-octave-gui" pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  5    Thread 0x7f90aed71700 (LWP 20775) "lt-octave-gui" pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  4    Thread 0x7f90ac570700 (LWP 20776) "lt-octave-gui" pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  3    Thread 0x7f90a9d6f700 (LWP 20777) "lt-octave-gui" pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  2    Thread 0x7f909adb6700 (LWP 20778) "QThread" 0x00007f90cc0a4b83 in select ()
    at ../sysdeps/unix/syscall-template.S:84
* 1    Thread 0x7f90cfd39940 (LWP 20638) "lt-octave-gui" 0x00007f90cc0a2dcd in poll ()
    at ../sysdeps/unix/syscall-template.S:84


And here's what gdb sees with OMP_NUM_THREADS=1 ./run-octave -qfH --no-gui


(gdb) info threads
  Id   Target Id         Frame
  2    Thread 0x7f8f005e9700 (LWP 20992) "QThread" 0x00007f8f200d0b83 in select ()
    at ../sysdeps/unix/syscall-template.S:84
* 1    Thread 0x7f8f23d65940 (LWP 20852) "lt-octave-gui" 0x00007f8f200cedcd in poll ()
    at ../sysdeps/unix/syscall-template.S:84


These additional threads are running on behalf of OpenBLAS for me, so something at startup triggers a BLAS routine to be called and kick off the OpenBLAS worker threads.

Mike Miller <mtmiller>
Group Member
Fri 10 Jun 2016 05:52:02 PM UTC, comment #69: 

I can confirm two fixes to use for breaking pause() statements

1) setenv OMP_NUM_THREADS 1 in the shell before starting Octave.
2) execute system() command that returns output.

The first solution is mostly for multi-threaded BLAS libraries, but it also works here indicating some dependence on threads.

The second case is pretty interesting.  A simple example that seems to reset the interrupt handlers is


system ("", 1)


All this does is call system and ask for the output back.  Internally, it seems that it is the creation of an iprocstream which probably resets things.  This is more easily proved by the following which also works


fid = popen ("", "r");


and the code in file-io.cc is


  if (mode == "r")
    {
      octave_stream ips = octave_iprocstream::create (name);

      retval = octave_stream_list::insert (ips);
    }


Just for fun, I commented out the retval statement and it still works so it is really the one statement to create an iprocstream that fixes things.

So, maybe jwe has an idea, but it seems that during the start-up sequence there is a lot of forking/execing and maybe not all of the std::streams get associated with the correct PID.


Rik <rik5>
Group administrator
Fri 10 Jun 2016 05:01:56 AM UTC, comment #68: 

I haven't seen this problem, because apparently the following line causes this to start working (explicitly shown here to cause a change in the way the terminal interrupts are handled):


./run-octave -qfH --no-gui
>> pause (10);
^C ## no effect, pause runs to completion
>>
>> [a,b] = system ("true");
>> pause (10);
^C
>> ## interrupt works now


My ~/.octaverc actually calls gnuplot, but the program that is called in system() doesn't seem to matter, what matters is that the output is captured with nargout == 2. This is enough to apparently restore terminal interrupt handling enough so that this works.

May have something to do with the octave-gui executable and doing something to the terminal attributes when it starts up.

Mike Miller <mtmiller>
Group Member
Fri 10 Jun 2016 04:01:08 AM UTC, comment #67: 

I pushed jwe's patch to interrupt system calls here (http://hg.savannah.gnu.org/hgweb/octave/rev/8fb87d3f0581).

For Linux, that leaves this one combination as unsolved.


./run-octave -f --no-gui
pause (5)
# type Ctrl+C


The Ctrl+C is at least recognized, but it goes to the SIGHANDLER which causes Octave to abort after 3 Ctrl+C keystrokes.

Rik <rik5>
Group administrator
Thu 09 Jun 2016 05:24:13 PM UTC, comment #66: 

Yes, I think jwe's patch is better than what we have now, It works for me for the subprocess example, doesn't break any of the other cases for me, assuming OMP_NUM_THREADS=1. FIXME makes it clear we need some more work done to make this better.

Incidentally, are braces required in this case where it's a single line of code but multiple lines of comments?

Mike Miller <mtmiller>
Group Member
Thu 09 Jun 2016 04:58:12 PM UTC, comment #65: 

Using jwe's patch from comment #51, the only failing instance from test #3 works.  However, jwe indicated in comment #51 that perhaps it should not be applied because it could lead to segfaults in multi-threaded BLAS libraries.

However, we already have that problem (bug #47400), so can we apply this anyways?

Rik <rik5>
Group administrator
Wed 08 Jun 2016 05:03:04 PM UTC, comment #64: 

So I don't see any segfaults (that aren't bug #47400).

Mike Miller <mtmiller>
Group Member
Wed 08 Jun 2016 05:02:44 PM UTC, comment #63: 

Yes, the segfaults due to multi-threaded BLAS implementations is bug #47400, let's keep that a separate issue, known for quite a while now.

With OMP_NUM_THREADS=1 and with "more off" run in the interpreter to make sure nothing is hanging on the pager subprocess, the only failure I can reproduce is


./run-octave -f ## with GUI
>> system ("sleep 5");
Ctrl+C
Ctrl+C
## interrupt signal is not sent to child processes


Mike Miller <mtmiller>
Group Member
Wed 08 Jun 2016 04:15:39 PM UTC, comment #62: 

Octave's handling of Ctrl+C interrupts is seriously compromised.  To begin with, I did all my testing on Linux (most stable of the OSes we support) with an up to date development tip (21835:f250714c629d).  I can repeatedly, and easily, get segfaults which lose all the work in the interpreter.  This is serious, so I have changed the severity to Blocker for the 4.2 release.

Test #1

I used Thorsten's code from comment #6 as the test vehicle.  I've attached that code to the bug report as tst_ctrlc.m.

Steps to reproduce:


./run-octave
tst_ctrlc
# Type Ctrl+C


Results:


./run-octave -f --no-gui-libs --no-line-editing : segfault
./run-octave -f --no-gui-libs                   : segfault
./run-octave -f --no-gui                        : segfault
./run-octave -f                                 : segfault


Test #2

Try to interrupt pause, which has always been problematic and has a different implemenation on Windows versus Linux.  See bug #44470 for a more complete description of the problems specific to Windows.

Steps to reproduce:


./run-octave
pause (5)
# Type Ctrl+C


Results:


./run-octave -f --no-gui-libs --no-line-editing : WORKS
./run-octave -f --no-gui-libs                   : WORKS
./run-octave -f --no-gui                        : FAILS, 3 Ctrl+C to kill Octave
./run-octave -f                                 : WORKS


Test #3

Try to interrupt a call to system() which has created a child process.

Steps to reproduce:


./run-octave
system ("sleep 5");
# Type Ctrl+C


Results:


./run-octave -f --no-gui-libs --no-line-editing : WORKS
./run-octave -f --no-gui-libs                   : WORKS
./run-octave -f --no-gui                        : WORKS
./run-octave -f                                 : FAILS, Ctrl+C never acknowledged


This appears to be multiple bugs manifesting in roughly the same way.  The segfault in test #1 is most likely due to the multithreaded nature of the BLAS library.  If I use


setenv OMP_NUM_THREADS 1


before starting run-octave then I no longer get segfaults and Ctrl+C seems to work.

Similarly, pause() has very different implementations between operating systems and it is likely that each OS needs that bit of code adapted in order to resolve test #2.

For test #3, it looks like the issue will be who is receiving the Ctrl+C indication.  Is it the embedded terminal process, the GUI Shortcut Manager, Qt itself, someone else?

My suggestion is that we start by building our understanding on the Linux platform and getting that to work correctly in 100% of cases.  From there, we can take what we know and apply it to solutions for Mac and Windows platforms. 



(file #37432)

Rik <rik5>
Group administrator
Wed 08 Jun 2016 11:03:24 AM UTC, comment #61: 

I thought there had been recent reports of crashes on Linux, Windows, and Mac OS X.

@Rik, how does the gui/cli for 4.0.2 and 4.1.0+ respond to multiple CTRL+C for you?

Ben Abbott <bpabbott>
Group Member
Wed 08 Jun 2016 07:01:32 AM UTC, comment #60: 

It has been over a year since Rik called for feedback.  I can personally confirm that the under Linux Ctrl+C works OK both for the GUI and CLI.

Can this bug be closed now, given bug #47927 is open?

Lachlan Andrew <lachlan>
Tue 17 May 2016 11:56:24 AM UTC, comment #59: 

For Ctrl-C crashes on Mac OS X

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

Ben Abbott <bpabbott>
Group Member
Mon 16 May 2016 12:07:45 AM UTC, comment #58: 

I just noticed that Ctrl+C followed by CR crashes with --no-gui. I'll open a new bug report.

Ben Abbott <bpabbott>
Group Member
Sat 14 May 2016 06:11:55 PM UTC, comment #57: 

I remember checking Ctrl+C on my Mac long ago and had no problem. However, with the 4.0.x it crashes. I'm on Mac OS X.

Ben Abbott <bpabbott>
Group Member
Fri 22 May 2015 03:36:27 PM UTC, comment #56: 

A lot of work has been done on the Ctrl+C processing in the GUI.  Can someone who was experiencing this error try the octave 4.0.0-rc4 available at ftp://alpha.gnu.org/gnu/octave/ and check if the problem is fixed?

Rik <rik5>
Group administrator
Thu 04 Dec 2014 11:38:57 PM UTC, comment #55: 

Suggested fix doesn't work - I ran the following:

clear ; close all; clc
fprintf('Running warmUpExercise ... \n');
fprintf('5x5 Identity Matrix: \n');

fprintf('Program paused. Press enter to continue.\n');
pause;

I get lots of beeps then:
clear ; close all; clc
fprintf('Running warmUpExercise ... \n');
fprintf('5x5 Identity Matrix: \n');

fprintf('Program paused. Press enter to continue.\n');
pause;

I hit Ctrl-c twice (should c be C?) - nothing works - what about
trying  (f)orward, (b)ack, (q)uit

Quit never works on Win 8 - all I can do is CTRL-ALT-DEL and kill the entire Octave program.


Angela Hey <amhey>
Sun 03 Aug 2014 08:37:42 AM UTC, comment #54: 

I have copied this comment on the behavior of Ctrl-C on windows (3.8.1) from bug #42867 by Nirmal:

Run the following script. Then press control-C twice when it pauses. We get prompt. Press Control-C again to abort.
Now press control-c again, to see program crash.


clear ; close all; clc
fprintf('Running warmUpExercise ... \n');
fprintf('5x5 Identity Matrix: \n');

fprintf('Program paused. Press enter to continue.\n');
pause;


Torsten Lilge <ttl>
Group Member
Fri 24 Jan 2014 08:19:13 PM UTC, comment #53: 

Marking as not a regression bug now. It was when Ctrl-C had been broken in CLI mode temporarily but was fixed well before the 3.8 release.

Mike Miller <mtmiller>
Group Member
Tue 10 Dec 2013 10:57:32 AM UTC, comment #52: 

I wanted to give a short update on this bug:

Linux (Kubuntu 13.04) with latest default tip (ec9b35e60f95):
No GUI: interrupting  a system command works as it should.... (good)
GUI: interruption does not work  (BAD!)

Windows using the latest mxe-octave (730fe4ac1a29):
No-GUI + GUI: It works in both cases (very good)

So to summarize:
Only Linux + GUI (the only combination I personally care about) does still not work at all... :(

Thorsten Liebig <thorsten>
Mon 25 Nov 2013 09:38:26 PM UTC, comment #51: 

I'm attaching a change that allows system() to be interrupted when running Octave with the GUI on Unixy systems.  However, I don't think we can use this change because it will make Octave crash when interrupting calls to multi-threaded BLAS functions, for example.

The only other thing I can think of is to somehow get (or track) the list of processes that are in the same process group as Octave and send SIGINT to all of them except the Octave process and then use pthread_kill to send SIGINT to the Octave interpreter thread.  Is there some easy way to get the list of processes in the process group?  If not, then it will take some work to keep track of the processes that we create, and it won't be possible to track all of the processes that might be created in .oct files (for example).

(file #29713)

John W. Eaton <jwe>
Group administrator
Thu 21 Nov 2013 10:32:58 PM UTC, comment #50: 

John,

If I interpret you correctly you are proposing
to start the release candidate process with the
system as it is now.

This definitely seems appropriate to me.

It is pretty likely that there will be sufficient
issues with RC1 to allow time for the items that
you listed to be resolved (if they have a viable
solution at all).


Michael Godfrey <godfrey>
Group Member
Thu 21 Nov 2013 10:22:23 PM UTC, comment #49: 

At this point, I think we are down to the following problems:

1. Interrupting readline input doesn't work when running the command-line version of Octave on Windows.

2. Interrupting system() doesn't work when running the GUI version of Octave on Unixy systems.

I'd really like to see both of these problems fixed before the release, but they don't necessarily have to be fixed before we make the first release candidate.

John W. Eaton <jwe>
Group administrator
Mon 18 Nov 2013 06:06:34 PM UTC, comment #48: 

This should have high priority, but if it
is still outstanding when other blockers are
cleared I would prefer that it NOT block the
release.

Michael Godfrey <godfrey>
Group Member
Mon 18 Nov 2013 05:50:01 PM UTC, comment #47: 

The current situation is that long-running Octave functions can be interrupted in the CLI, --no-gui, and GUI versions of Octave.

Example Code 1 : Internal function


sleep (10);


For commands outside of Octave, the function can be interrupted in the CLI and --no-gui versions, but not in the GUI.

Example Code 2 : External function


system ("sleep 10");


This is still listed as a blocker on the 3.8. Bug Fix list.  Do we still consider that to be the case, or is this fixed enough for the release?

Rik <rik5>
Group administrator
Fri 15 Nov 2013 03:34:08 AM UTC, comment #46: 

It's unclear to me what has been fixed and should work now, I haven't been following too closely.

Built tonight, I can interrupt long-running Octave functions, but interrupts do not seem to be sent on to child processes invoked from Octave, e.g. through system(). Is this expected or should be working now?

Doing either system("sleep 30") or system("watch ls") in the GUI results in something that can't be interrupted at all.

Also making "less" come up and then pressing "F" to enter tail mode results in something that can't be interrupted (this was reported in another bug that I marked as a duplicate of this one).

Mike Miller <mtmiller>
Group Member
Thu 14 Nov 2013 07:48:36 PM UTC, comment #45: 

I'm NOT running on Windows of course ;)

I use Kubuntu 13.10 and 13.04 on another machine and it is not working for me. Strange...
Am I the only one??

I'm just occasionally building and testing the mxe-version for Windows...


Thorsten Liebig <thorsten>
Thu 14 Nov 2013 07:41:32 PM UTC, comment #44: 

Thorsten: Are you running on Windows?

Yes, it used to work but Ctrl-C as copy did not work.  Apparently, people want both of these things to work.

It does work for me now on my Debian system.  So I think the problem is fixed for Unixy systems with pthreads.

I don't expect it to work properly on Windows systems yet.

John W. Eaton <jwe>
Group administrator
Thu 14 Nov 2013 07:31:40 PM UTC, comment #43: 

jwe: I was using 345a8027dc8b with a fresh build folder.

But I have just now tried again with a fresh hg clone (now 97bde75d4119)
What was the command for a clean clone? hg purge ?

fresh clone
./bootstrap
mkdir / cd .build
../configure
make -j3
./run-octave

and I am still unable to interrupt a system('sleep 10') or anything similar.

with ./run-octave --no-gui everything works fine...

So no improvement for me :(

And I might again point out my first comment, that with Octave 3.7.5 with mxe on Windows, CTRL+C worked like it should, but stopped at some point and started behaving like on Linux...

regards
Thorsten

Thorsten Liebig <thorsten>
Thu 14 Nov 2013 04:31:59 PM UTC, comment #42: 

Thorsten: I think it should work.

How did you build?  Rik mentioned that he had trouble until he built from scratch.  I don't know whether that is really needed, but maybe there was some problem with the build for you that causes trouble.

What is your hg id?

How are you running Octave?

John W. Eaton <jwe>
Group administrator
Thu 14 Nov 2013 04:02:35 PM UTC, comment #41: 

jwe: changes from the latest commits you made. I thought Rik meant that CTRL+C now works within the GUI...
But the current tip does not show any change in behavior for me (Kubuntu 13.04)

Thorsten Liebig <thorsten>
Thu 14 Nov 2013 04:01:04 PM UTC, comment #40: 

Just run octave-cli seems better to me.
The command-line option seems potentially
confusing, and there are a lot of those already.

Michael Godfrey <godfrey>
Group Member
Thu 14 Nov 2013 03:54:27 PM UTC, comment #39: 

Maybe we should document --no-gui-libs.  Or you can just run octave-cli directly.

John W. Eaton <jwe>
Group administrator
Thu 14 Nov 2013 03:53:41 PM UTC, comment #38: 

Thorsten: Change from what?

John W. Eaton <jwe>
Group administrator
Thu 14 Nov 2013 03:52:44 PM UTC, comment #37: 

--no-gui works fine as ever, but I don't see any change with the GUI? Am I supposed to?



Thorsten Liebig <thorsten>
Thu 14 Nov 2013 03:48:31 PM UTC, comment #36: 

--no-gui
and ctrl-c works for me, too.  Very good.

Since --no-gui-libs is not documented is it
intended for some "internal" purpose?

Michael Godfrey <godfrey>
Group Member
Thu 14 Nov 2013 03:35:57 PM UTC, comment #35: 

All three ways of invoking Octave now work with


sleep (10);
Ctrl+C


Rik <rik5>
Group administrator
Thu 14 Nov 2013 03:14:13 PM UTC, comment #34: 

Maybe we won't have to make --no-gui mean --no-gui-libs.  I checked in the following change:

  http://hg.savannah.gnu.org/hgweb/octave/rev/345a8027dc8b

This seems to fix the problem for me with signal handling and the --no-gui option.  It should work on systems that use pthreads.  It won't do anything for us on Windows systems.  I'll post something on the maintainers list about signal handling and Windows.

John W. Eaton <jwe>
Group administrator
Thu 14 Nov 2013 01:16:35 PM UTC, comment #33: 

Good. For the 3.8 release making --no-gui mean --no-gui-libs
seems fine. Getting Qt GUI elements to work can be done
later.  Just having GUI or --no-gui is better than three flavors
anyhow. And, there is enough work on blockers already.

So, I am for making --no-gui mean --no-gui-libs.  If it is
needed for testing Qt in no-gui mode some other temporary
mechanism can be used.

Michael Godfrey <godfrey>
Group Member
Thu 14 Nov 2013 06:25:46 AM UTC, comment #32: 

I mean that Qt GUI elements will not work from the command line interface.  FLTK plotting will still work.  But we would like to use Qt widgets for plotting and UI elements, and I think that should work from the command line.  Michael Goffioul had that working with QtHandles, though I'm not sure what the status of interrupt handling was with his wrapper program that set up the Qt application context.

John W. Eaton <jwe>
Group administrator
Thu 14 Nov 2013 06:21:09 AM UTC, comment #31: 

John,

I think that for now the change that you propose
of making --no-gui mean --no-gui-libs is OK.

But, what do you mean by "graphics may not work"?
If this change breaks the standard usage of fltk
and gnuplot, then I think that has to be fixed.

I just tried a number of plots using fltk and saw
no problems.

Michael Godfrey <godfrey>
Group Member
Thu 14 Nov 2013 06:03:20 AM UTC, comment #30: 

The idea is for --no-gui-libs to bring up a command-line only version of Octave in which graphics and any graphical user interface elements might not even work.  The --no-gui option should start Octave in a command-line mode that still allows graphics and ui* functions to work.  But currently the --no-gui thing is not really working, so I'm beginning to think that we should just make --no-gui mean the same as --no-gui-libs for the 3.8 release.  Then interrupt handling is solved for those two cases.  It also looks like the pthread_kill/pthread_sigmask thing works for the GUI in Unix systems.  Then we are just left with making interrupts work properly for Windows systems.

John W. Eaton <jwe>
Group administrator
Wed 13 Nov 2013 11:31:08 PM UTC, comment #29: 

OK. That is it.

I have been running, due to .octaverc, in
effect octave --no-gui

If I run octave --no-gui-libs
ctrl-c works.

What is octave --no-gui for these days?

Is --no-gui-libs the right way to get --no-gui?


Michael Godfrey <godfrey>
Group Member
Wed 13 Nov 2013 11:25:02 PM UTC, comment #28: 

I think there has been a regression, although I'll have to go back and re-compile to make sure.  Here are my results on the most recent tip:

run-octave -f : works (in GUI)
run-octave -f --no-gui-libs : works (in raw CLI)
run-octave -f --no-gui : BAD

Maybe the problem is that when running --no-gui the CopyClipboard function is not available since the GUI isn't running.

Rik <rik5>
Group administrator
Wed 13 Nov 2013 11:08:35 PM UTC, comment #27: 

Rik,

Did your system respond to ctrl-c after full cleaning?

Michael Godfrey <godfrey>
Group Member
Wed 13 Nov 2013 11:02:55 PM UTC, comment #26: 

I tried:

kill -INT 5875

no effect
kill -9 5875
killed octave (just proves I had the PID right.)

Michael Godfrey <godfrey>
Group Member
Wed 13 Nov 2013 10:51:50 PM UTC, comment #25: 

Michael,

I also had the same problem where Ctrl+C was not recognized after just doing "hg pull; hg update; make".  In the end, 'make clean' and 'make distclean' were not enough.  I had to run 'make maintainer-clean' and then also delete libgui/src/src_libgui_src_la-octave-main-thread.lo.  Then I re-ran the bootstrap, configure, and make cycle.

Rik <rik5>
Group administrator
Wed 13 Nov 2013 10:01:16 PM UTC, comment #24: 

Michael Godfrey:

What about the test with "kill -INT PID":

What happens if you execute "sleep (200)" at the Octave prompt and then do "kill -INT PID" with PID == the process ID of the Octave process? This should be the one that is shown as "octave" in the output from ps, not the "lt-octave-gui" process.

Does that deliver an interrupt signal to Octave?  If so, does it interrupt the sleep function?

I'm trying to determine whether it is a problem with Ctrl-C not being acted on by Qt (we expect that it is defined as a keyboard shortcut that will eventually put us in the copyClipboard function in the terminal widget) or if it is that signal handling is not working.

John W. Eaton <jwe>
Group administrator
Wed 13 Nov 2013 08:29:26 PM UTC, comment #23: 

I just did a complete rebuild and get
the same results as below.  No sign of the
ctrl-c being seen at all.

Michael Godfrey <godfrey>
Group Member
Wed 13 Nov 2013 06:14:20 PM UTC, comment #22: 

On Windows, interrupting a loop like "more off; for i = 1:100000, i, end" should work, but interrupting an external library function like "inv (large_matrix)" probably won't work becuase the setjmp/longjmp thing fails.

John W. Eaton <jwe>
Group administrator
Wed 13 Nov 2013 06:03:01 PM UTC, comment #21: 

I did a full maintainer-clean, followed by bootstrap, configure, make to get rid of any cruft.  After getting past the missing config.h include in octave-dock-widget.cc, I now have Ctrl+C working on a Mint (Debian-derivative) system.  I will try and cross-compile for MinGW and see how it works over there.

Rik <rik5>
Group administrator
Wed 13 Nov 2013 06:02:11 PM UTC, comment #20: 

Sorry, I meant:

Also, what happens if you select some text in the command window and type Ctrl-C? Does it copy the selected text to the clipboard so that Ctrl-V copies it to the command prompt?

John W. Eaton <jwe>
Group administrator
Wed 13 Nov 2013 05:59:34 PM UTC, comment #19: 

What happens if you execute "sleep (200)" at the Octave prompt and then do "kill -INT PID" with PID == the process ID of the Octave process?  This should be the one that is shown as "octave" in the output from ps, not the "lt-octave-gui" process.

Also, what happens if you select some text in the command window and type Ctrl-C?  Does it paste the selected text?

Does Ctrl-C give you a new prompt when Octave is otherwise idle and waiting for input?

Does Ctrl-C interrupt loops like "more off; for i = 1:1000000; i, end"?

John W. Eaton <jwe>
Group administrator
Wed 13 Nov 2013 04:47:13 PM UTC, comment #18: 

Michael, what happens if you type Ctrl-C when inv is working on a large matrix?  For example


x = rand (3000);
inv (x);


Pause for a half second or so before interrupting the inv command because there is a call to std::copy at the top of that function that must complete before you get to the code that will react to SIGINT by doing a longjmp.  If you type Ctrl-C twice while the std::copy is working, you'll get a message about typing Ctrl-C again to abort Octave.  If you do that before reaching the code where Octave uses setjmp/longjmp, you'll exit Octave.

What about if you go back to the changeset prior to my latest patches?  Try "hg up -C c9f622fd7307", then build again and try the test above.  I expect that Octave will exit when you type Ctrl-C, and that will happen without the message about typing Ctrl-C again to abort.  So without the patches, interrupting doesn't work properly.  With them, I'm hoping that it is just sleep that is affected.

John W. Eaton <jwe>
Group administrator
Wed 13 Nov 2013 04:00:22 PM UTC, comment #17: 

I just tried the latest fixes from John.
But, for Fedora 19, they seem not to work.
Now, running sleep(2) in any form results
in ctrl-c not being handled at all.

I tried:
octave:3> system("sleep 20")
^C^C^Cans = 0
octave:4> sleep(2)
^Coctave:5> sleep(20)
^C^C^C^Coctave:6>
octave:6> system("sleep 20")
^C^C^C^Cans = 0
octave:7>
=============================
Before, 2 ctrl-c's worked.  So, this fix
is a regression.  Getting interrupts to work
right is one of serious problems in today's
popular systems.

But, for Fedora linux at least, reverting this
latest set of patches would be better.

Michael Godfrey <godfrey>
Group Member
Thu 17 Oct 2013 09:41:41 PM UTC, comment #16: 

I can confirm that problems with handling Ctrl-C while the interpreter is sleeping is not limited to Windows.  I looked at it but could not find a quick fix.

John W. Eaton <jwe>
Group administrator
Thu 03 Oct 2013 04:12:26 PM UTC, comment #15: 

(In response to Mike's request at bug #40156)

In 3.7.6+ GUI (MXE-cross-built, on WinXP), trying to interrupt 'system ("sleep 50")' doesn't work. I get after Ctrl-C twice separated three secs apart:

octave-cli.exe:1> system ("sleep 50")
Press Ctrl-C again to abort


...and the next (3rd) Ctrl-C kills Octave with an error about
"The instruction at '0x67777e70' referencing memory at '0x00000000'. The memory could not be read
Click OK to terminate the program"

I tend to suspect this is due to Octave calling an external program; either Octave doesn't correctly transfer the interrupt to sleep(), or sleep() itself doesn't want to be interrupted (improbable I think), or Octave doesn't correctly pick up sleep()'s return. I'd go for the first because sleep() goes on and on.... it apparently never gets the signal.

However... in 3.7.6+ CLI, interrupting 'system ("sleep 50")' gives (after Ctrl-C within 3 secs):

octave-cli.exe:1> system ("sleep 50")
ans =  258

octave-cli.exe:1>


and promptly returns to the prompt (no pun intended) after Ctrl-C so in the CLI it works OK (I can only vouch for my own box, of course).
FYI, on 3.6.4 the return value is 0 rather than 258.

Internal stuff (i.e., scripts, Octave commands) CAN be interrupted - already in Octave-3.6.4. I never noted a regression. I've been busy lately with processing (big) spreadsheets; time-consuming stuff like complicated regexps on MB size strings can be aborted, w/o effects for stability etc.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 28 Jul 2013 07:38:47 PM UTC, comment #14: 

Setting status back to confirmed since we have a couple of cases here that are not responding to user interrupt correctly.

Here's another one:


octave:1> system ("sleep 5")
^Cans = 2


In the command line, any child process receives the SIGINT, in this case the command exits immediately and the exit status is non-zero.

Same with the 'F' command in the less pager, which runs to the end of the input and waits for a user interrupt. If it cannot be interrupted, it never returns and Octave has to be killed. See bug #37468 (assigning as a duplicate of this bug now).

In the GUI both of these examples just hang, the child process does not receive the SIGINT.

Mike Miller <mtmiller>
Group Member
Wed 17 Jul 2013 06:33:14 PM UTC, comment #13: 

With a fresh build, the cli version aborts correctly on my system, too.



Torsten Lilge <ttl>
Group Member
Tue 16 Jul 2013 08:17:45 AM UTC, comment #12: 

The same for me, runs and aborts clean as expected in cli-mode and crashes in GUI mode...
To me the command line interface looks all good...

Thorsten Liebig <thorsten>
Tue 16 Jul 2013 05:08:46 AM UTC, comment #11: 

It does not crash for me in command-line mode, it just breaks out of the loop immediately as it should:


$ cat testloop.m
for n=1:1e4
tic
m = randn(2000,2000);
im = inv(m);
disp(num2str(n))
toc
end
$ octave-cli -qf
octave-cli:1> testloop
^C1
Elapsed time is 5.48175 seconds.

octave-cli:1>


Mike Miller <mtmiller>
Group Member
Mon 15 Jul 2013 08:30:15 PM UTC, comment #10: 

Also the cli version of crashes when trying to abort Thorsten's second example with ctrl-c. This does not seem to be a gui problem. The error message is:

+verbatim*
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
-verbatim-

Torsten Lilge <ttl>
Group Member
Mon 15 Jul 2013 05:41:52 PM UTC, comment #9: 

Even the mxe build on windows does not abort a sleep () or Thorsten's second example with Ctrl-C (or with Ctrl-Shift-C) before the patch).

Torsten Lilge <ttl>
Group Member
Mon 15 Jul 2013 07:46:07 AM UTC, comment #8: 

Well in my case it does not even exit, I have to kill (SIGKILL) the frozen GUI manually...

Thorsten Liebig <thorsten>
Sun 14 Jul 2013 11:36:31 PM UTC, comment #7: 

Confirmed Thorsten's second example here, running the GUI in gnome shell. The GUI exits immediately as soon as ctrl-c is pressed while in the computational loop.

Mike Miller <mtmiller>
Group Member
Sun 14 Jul 2013 11:55:44 AM UTC, comment #6: 

What do you mean by normal script?

I tried this (as a script):

for n=1:1e4
sleep(3)
disp(num2str(n))
end


If I hit CTRL+C it aborts after the next sleep is done. It seems that the GUI (on Linux) is unable to interrupt a command and can only stop the script after a sleep is done??

I tried something more useful than sleep:

for n=1:1e4
tic
m = randn(2000,2000);
im = inv(m);
disp(num2str(n))
toc
end


trying to abort this with CTRL+C, ends up in a complete hangup/freeze and crash of Octave :(

Something here is pretty broken, at least for me...


Thorsten Liebig <thorsten>
Sun 14 Jul 2013 11:34:35 AM UTC, comment #5: 

I can conform the effect that sleep can not be aborted and will have a look at it.

Thorsten, are normal octave-scripts interrupted by ctrl-c on kubuntu?

Torsten Lilge <ttl>
Group Member
Sat 13 Jul 2013 10:21:27 PM UTC, comment #4: 

I do see that ctrl-c does cancel the current line being edited if no text is selected. It also does break out of a long-running for loop. But I don't see the following working in the GUI, which works fine in terminal mode:


octave:1> sleep (5);
ctrl-c


first ctrl-c: nothing happens
second ctrl-c: "Press Control-C again to abort."
third ctrl-c: Octave exits

So the interrupt is being caught by sigint_handler, but does not break the sleep function.

Mike Miller <mtmiller>
Group Member
Sat 13 Jul 2013 06:32:01 PM UTC, comment #3: 

I do NOT see any change on my Kubuntu!

I'm still unable to abort my scripts using crtl+c

Maybe it is important to add some more details:

I'm running an external binary for my numerical simulations using the octave "unix" command and it is this process the Octave-GUI can't interrupt.
As a matter of fact, I can't exit the GUI at all. The close button or File->Exit do not react as well. Not even a normal process kill (SIGTERM) does it.
After the unix command finishes the GUI crashes.. but only if I tried to abort it with CTRL+C

With the "no-gui", octave reacts as expected and as I mentioned so does the GUI and no-gui version for Windows (mxe build).

regards
Thorsten

Thorsten Liebig <thorsten>
Thu 11 Jul 2013 07:27:56 PM UTC, comment #2: 

Changeset http://hg.savannah.gnu.org/hgweb/octave/rev/eefcfeb37446
fixes the issue on my system (ubuntu). The terminal already aborted a command with the copy shortcut but this was configured to ctrl+shift+c up to now. Just configuring to the right shortcut ctrl+c solved the problem.

I am leaving the report open until the fix is confirmed on other systems.

Torsten Lilge <ttl>
Group Member
Fri 24 May 2013 08:57:50 PM UTC, comment #1: 

I just recently build the mxe-octave version for Windows. To my surprise the Windows version reacted correctly to the STRG+C by aborting the script. The Linux Octave Gui is still affected though...

Unfortunately I have no idea how to fix this...

Thorsten Liebig <thorsten>
Tue 06 Nov 2012 09:03:06 AM UTC, original submission:  

If running a long command or script within the new Octave GUI it cannot be aborted with CTRL+C (or any other way) since it is not recognized!

I like the new GUI very much, but I run very lengthy numerical simulations and not being able to abort them is a real show-stopper for me. I have to kill (no reacting to quit or CTRL+Q either) the GUI and restart every time losing my workspace & results in the process...

I have tested this with the latest hg version on Linux.
"octave --no-gui" is not affected of course.
(http://hg.savannah.gnu.org/hgweb/octave/rev/80a4ded6b89c)

Thorsten Liebig <thorsten>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #37432:  tst_ctrlc.m added by rik5 (76B - d2l/unknowntype)
file #29713:  diffs-system-interrupt.txt added by jwe (1KiB - text/plain)

 

Carbon-Copy List
  • -email is unavailable- added by lachlan (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by amhey (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  •  

    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 18 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-08 jwe StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2016-07-12 lachlan Item GroupIncorrect Result Segfault, Bus Error, etc.
        StatusConfirmed Patch Submitted
    2016-06-08 mtmiller Dependencies- Depends on bugs #47400
    2016-06-08 rik5 Attached File- Added tst_ctrlc.m, #37432
        Severity4 - Important 5 - Blocker
        SummaryGUI doesn't react to CTRL+C CTRL+C interrupt processing causes segfaults
    2014-08-03 rik5 Carbon-CopyRemoved 72865 -
    2014-01-24 mtmiller Item GroupRegression Incorrect Result
    2013-11-25 jwe Attached File- Added diffs-system-interrupt.txt, #29713
    2013-11-21 rik5 Severity5 - Blocker 4 - Important
    2013-11-08 jwe Severity3 - Normal 5 - Blocker
    2013-07-28 mtmiller Dependencies- bugs #37468 is dependent
    2013-07-28 mtmiller StatusReady For Test Confirmed
    2013-07-11 ttl StatusConfirmed Ready For Test
    2013-05-29 rik5 Carbon-CopyRemoved 72865 -
    2013-04-11 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code