bugGNU Octave - Bugs: bug #44470, Pause does not detect Ctrl+C...


bug #44470: Pause does not detect Ctrl+C keystroke in Windows GUI

Submitter:  -X- <jsh>
Submitted:  Sat 07 Mar 2015 02:23:45 PM UTC
Category:  Interpreter Severity:  4 - Important
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.0.0 Operating System:  * Microsoft Windows
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Thu 08 Mar 2018 08:45:28 PM UTC, comment #24: 

Closing this as fixed because I think we do the right thing now with pause and Ctrl-C, at least for the development sources.  It works for me on Windows with the current stable and dev sources.

John W. Eaton <jwe>
Project Administrator
Thu 26 May 2016 03:29:24 AM UTC, comment #23: 

The GUI is multi-threaded.  It is quite possible that there is confusion about which thread is receiving the SIGINT.

Rik <rik5>
Project Administrator
Thu 26 May 2016 01:06:49 AM UTC, comment #22: 

Correction of comment #21

Execute the above and press Ctrl+C while for loop is active.
Ctrl+C aborts the loop and do not go disp('Outside for loop').
This is expected behavior.
The above works correct both cli and gui. (<= add sentence)

Tatsuro MATSUOKA <tmacchant>
Thu 26 May 2016 01:03:14 AM UTC, comment #21: 

Simple script

more off
for i=1:5000; rand(5000,5000), end
disp('Outside for loop')

Execute the above and press Ctrl+C while for loop is active.

Ctrl+C aborts the loop and do not go disp('Outside for loop').

This is expected behavior.

In the case of pause for GUI,

Press Control-C again to abort.
appear before crash by pressing Ctrl+C.
This means that Ctrl+C itself is recognized.

I now think that this is not a trapping Ctll+C handler issue but a issue of cause a segfault by Ctrl+C interrupt
at some idling states.

Macro reported that on

I can obtain the same results with sombrero()
if I hit CTRL+C 3 times before the plot is completed.

octave:1> more off
octave:2> sombrero()
Press Control-C again to abort.
panic: Interrupt -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete

Tatsuro MATSUOKA <tmacchant>
Wed 25 May 2016 10:53:12 PM UTC, comment #20: 

Debugging who is receiving the Ctrl+C is always complicated.  In this case, it might be the embedded console or it might be the Qt application.  In the first case, is the normal interrupt handler still in place?  In the second case, is Ctrl+C being intercepted by the Qt shortcut mechanism looking for the "Copy" shortcut?

Simplest code to test is just


A single Ctrl+C keystroke should break the pause command, but doesn't.

Rik <rik5>
Project Administrator
Wed 25 May 2016 12:41:04 PM UTC, comment #19: 

seems likely related to Ctrl-C crashing MacOS:


Nicholas Jankowski <nrjank>
Project Member
Wed 25 May 2016 12:24:23 PM UTC, comment #18: 

Here's a simple test that crashes both octave-gui and octave-cli on Windows (verified 4.0.2, Windows 7, 32 bit zip installer)

I've found a simple script to crash Octave CLI. Here's the script:
> A = rand(200,1);
> disp(A);
> Steps to reproduce:
> Run the script.
> When you see the '--- less --- (f)orward, (b)ack, (q)uit' prompt, press
> CTRL-C twice.
> When you see 'Press Control-C again to abort.', press CTRL-C again.
> If you look at the sequence, both Octave GUI and CLI crashes after three
> CTRL-C keystrokes are pressed.

when running from octave-cli, the less.exe process is left running (but idle) after octave crashes out.

Actually, after running disp(A), a single instance of less.exe is created. Pressing ctrl-c once seems to do nothing. Pressing it again you get the message 'Press Control-C again to abort'.  On the third press, I get a "attempting to save variables to 'octave-workspace' ... save to 'octave workspace' complete" after which a Windows crash window "octave-cli.exe has stopped working..." window appears.

Even clicking the Close this program button, the CLI window stays greyed out, but present. less.exe is still present. Unable to close the window except by manually terminating the less.exe process.

from the same help list discussion:

Nicholas Jankowski <nrjank>
Project Member
Wed 25 May 2016 11:06:29 AM UTC, comment #17: 

Sorry I have completely misled.
Octave-gui is also console program with (perhaps) hidden console window.

Thus Ctrl+C also works on octave gui but it does not work correctly.

Press Control-C again to abort

means that Ctrl+C is detected by the implemented mechanism.
However, the second press Ctrl+C causes octave segfault.

I have succeeded building octave for windows on the native windows [1].
I will try to run octave by ./run-octave -g tommorrow.

[1] http://octave.1599824.n4.nabble.com/Octave-build-on-windows-using-octave-binary-itself-td4676652.html

Tatsuro MATSUOKA <tmacchant>
Wed 25 May 2016 10:06:32 AM UTC, comment #16: 

For me octave-cli works correct using example on comment #14.
(tested 4.0.2 32 and 64 bit.)

However, octave gui hangs as is written in comment #14.

I concluded that a new implementation routine for Ctrl+C for octave-cli for windows does not have issue.

This is a issue of octave-gui.

From here my guess:
This is not a problem of Ctrl+C handler. Ctrl+C key press has special meaning only on console program at least for windows. For octave-GUI, we might implement it using completely different way.

Tatsuro MATSUOKA <tmacchant>
Wed 25 May 2016 09:50:28 AM UTC, comment #15: 

I think bug #44485 is closely related.
That's about closing Octave from the main GUI menu while it is busy, but the mechanism and the results (crashes) looks very much the same.

Unfortunately Dan and I didn't have time / priority to pick up again after last summer.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 25 May 2016 07:29:13 AM UTC, comment #14: 


Original committer seems not to be able to make account here.

I will write instead of him.

Here's a simple script that crashes Octave GUI all the time.

clear; close all; clc

x = [1; 2; 3; 4];
y = x;

plot(x, y, 'rx', 'MarkerSize', 10);
fprintf('Program paused. Press enter to continue.\n');

The steps to reproduce is:

1. cd the to directory that contains the script.
2. Run the script.
3. When you see "Program paused. Press enter to continue", press CTRL-C twice.
3. Now, you should see "Press Control-C again to abort.".
4. Press CTRL-C again. Then Octave GUI crashes.

Tatsuro MATSUOKA <tmacchant>
Wed 25 May 2016 05:59:12 AM UTC, comment #13: 

I could not understand the situation. For Octave GUI, it works on QT GUI layer, doesn't it? If so the KeyPress event should be acquired from QT, shouldn't be ?
Shouldn't we learn how the Qt GUI for windows treats key events?

For CLI interface, it is working on true windows console mode so that windows API for CtrlC handler API can be used.

Am I misled?

Tatsuro MATSUOKA <tmacchant>
Wed 25 May 2016 05:04:09 AM UTC, comment #12: 

I've re-titled the bug report.

See my comment #8.  The issue is that the _getch routine from Microsoft does not detect Ctrl+C.  Documentation is at https://msdn.microsoft.com/en-us/library/078sfkak.aspx.

One possibility is to see whether using SetConsoleMode to treat Ctrl+C as an ordinary character will work.  See http://stackoverflow.com/questions/18291284/handle-ctrlc-on-win32.

Rik <rik5>
Project Administrator
Wed 25 May 2016 02:37:04 AM UTC, comment #11: 

Perhaps I am confusing the situation. Meaning of pressing Ctrl+C is different between in GUI and in CLI.  For GUI, pressing Ctrl+C is mere a one of the key presses.
However on CLI, pressing Ctrl+C gives interrupt and should be treated as an interrupt. I quickly look the codes for the latter I cannot find any problem due to my limited knowledge.

Sorry if I am still confusing.

Tatsuro MATSUOKA <tmacchant>
Wed 25 May 2016 12:16:38 AM UTC, comment #10: 



Is the above related to this tracker?
If it is not, is (are) there (a) similar issue(s)?

Tatsuro MATSUOKA <tmacchant>
Wed 25 May 2016 12:13:28 AM UTC, comment #9: 

Since octave 3.8, Ctrc+C handler was entirely modified.

For octave 3.6 or before it is written in src/signalhandler.cc.
Since octave 3.8, it is written in libinterp/corefcn/sighandlers.cc and libgui/src/thread-manager.cc

Before 3.6.4 it was written src/signalhandler.cc, The codes for windows were written using windows API directly.  IIRC, Ctrl+C handing was well done. I think that new implementation is not good as the previous implementations. Of course, I do not say that we have to back the earlier implementations. However, current implementation should be improved as effective as before.

Tatsuro MATSUOKA <tmacchant>
Thu 03 Dec 2015 04:01:55 AM UTC, comment #8: 

Windows and Linux were using completely different code (protected by #ifdefs) to implement the kbhit/pause routines.  I have updated the code for Windows to actually work by using the _kbhit and _getch routines which are pretty much Windows specific.  See http://hg.savannah.gnu.org/hgweb/octave/rev/a8ee668e7fd7.

However, these routines don't detect Ctrl+C as a keypress.  That seems to be specially handled by the terminal.  Leaving this bug as confirmed and open until there is a fix for that.

Rik <rik5>
Project Administrator
Tue 02 Jun 2015 04:36:53 PM UTC, comment #7: 

Retagging release from 4.0.0-rc1 to 4.0.0.

John W. Eaton <jwe>
Project Administrator
Tue 12 May 2015 01:24:25 AM UTC, comment #6: 

Yes, still get a 'memory could not be read' crash after I hit ctrl-c the second time. Linux works now but the odd thing is that on linux I don't see the 'Press Control-C again to abort' prompt.

-X- <jsh>
Sun 03 May 2015 10:35:17 PM UTC, comment #5: 

@jsh: can you try this again with the current rc4 for Windows and see if the same problem still happens?

Mike Miller <mtmiller>
Project Administrator
Sun 08 Mar 2015 01:37:50 AM UTC, comment #4: 

I've noticed a similar thing on linux.  It's difficult to repeat.  I've been working on a demo that uses inputdlg and similar functions.  I had problems printing a plot because the figure disappeared before the print command executed (when it seemed like that shouldn't happen).  So I placed "pause(0)" in the code to force a drawnow().

It seems that if I hit control-c during the inputdlg display, sometimes Octave GUI will crash right after returning from the dialog box closing.  Now, those inputdlg() routines aren't the best programmed.  They were just something to get started.  (A good comm concept is needed.)  Nonetheless, I thought they were fairly robust in the past.  So I'm more inclined to think there is a connection to "pause".

In any case, another strange thing is that if I type "cancel" for the dialog box, it's as if the lines of code after the inputdlg() don't get run, but when hitting OK they do.  It's all sort of vague.  But maybe the signal is being corrupted somehow, e.g., a cancel causes a bogus signal to the core????  Not much help, I know.

Dan Sebald <sebald>
Sat 07 Mar 2015 11:07:42 PM UTC, comment #3: 

Tested on my Win 8.1 installation and Ctrl+C doesn't register, but on my XP 32 it does register and after I hit Ctrl+C twice (first time it gives a message to press again to abort) it crashes with memory error. Could be my XP installation is old and crufty though. Will retest on linux after I've updated.

-X- <jsh>
Sat 07 Mar 2015 06:42:04 PM UTC, comment #2: 

Thanks for your bug report. I can't reproduce this on either Linux or Windows XP. On Linux, Ctrl-C makes the pause function return immediately. On Windows, Ctrl-C does nothing, pause only returns when I hit Enter.

Mike Miller <mtmiller>
Project Administrator
Sat 07 Mar 2015 02:41:16 PM UTC, comment #1: 

I should add it only happens if I run in the QtGUI, cli or no gui seems to work fine.

-X- <jsh>
Sat 07 Mar 2015 02:23:45 PM UTC, original submission:  

I get a crash if I just type a pause and then hit ctrl-c once or twice. I first noticed in the 4.0rc1 Windows build but checking I get it on my dev branch on Linux too.

-X- <jsh>


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

Attach Files:

No files currently attached


Depends on the following items: None found

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by tmacchant (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by jsh (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 project members can vote.





    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-08 jwe StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2016-07-01 rik5 Severity3 - Normal 4 - Important
    2016-06-20 mtmiller Dependencies- bugs #48279 is dependent
    2016-05-25 rik5 SummaryCtrl+C after pause gives crash/segfault on Windows Pause does not detect Ctrl+C keystroke in Windows GUI
    2016-05-17 mtmiller Summaryctrl-c after pause gives crash/segfault Ctrl+C after pause gives crash/segfault on Windows
    2015-12-03 rik5 StatusWorks For Me Confirmed
    2015-06-02 jwe Release4.0.0-rc1 4.0.0
    2015-05-03 mtmiller CategoryNone Interpreter
    2015-03-07 mtmiller StatusNone Works For Me

    Back to the top

    Powered by Savane 3.9