bugGNU Octave - Bugs: bug #53635, CTRL-C does not work in all...

 
 

bug #53635: CTRL-C does not work in all instances when using Windows GUI

Submitter:  Avinoam Kalma <avinoam>
Submitted:  Fri 13 Apr 2018 11:34:47 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.3.90 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 19 Apr 2018 03:13:33 PM UTC, comment #27: 

Works for me.  Marking as fixed and closing report.

I think we are ready for a 4.3.91 release candidate.

Rik <rik5>
Group administrator
Thu 19 Apr 2018 03:10:07 PM UTC, comment #26: 

OK, I decided to try again with Windows.  Since I removed the call


GenerateConsoleCtrlEvent (CTRL_C_EVENT, 0);


in http://hg.savannah.gnu.org/hgweb/octave/rev/4adeabc1bbfe, things like


system ("sleep 10");


can't be interrupted on Windows systems.  So I thought I would try again, and made the following change:


diff --git a/libgui/src/terminal-dock-widget.cc b/libgui/src/terminal-dock-widget.cc
--- a/libgui/src/terminal-dock-widget.cc
+++ b/libgui/src/terminal-dock-widget.cc
@@ -27,6 +27,10 @@ along with Octave; see the file COPYING.

 #include <QDesktopWidget>

+#if defined (OCTAVE_USE_WINDOWS_API)
+#  include <windows.h>
+#endif
+
 #include "quit.h"
 #include "signal-wrappers.h"

@@ -113,6 +117,12 @@ namespace octave
     octave_signal_caught = 1;
     octave_interrupt_state++;

+#if defined (OCTAVE_USE_WINDOWS_API)
+
+    GenerateConsoleCtrlEvent (CTRL_BREAK_EVENT, 0);
+
+#else
+
     // Send SIGINT to all other processes in our process group.
     // This is needed to interrupt calls to system (), for example.

@@ -120,5 +130,7 @@ namespace octave
     octave_get_sig_number ("SIGINT", &sigint);

     octave_kill_wrapper (0, sigint);
+
+#endif
   }
 }


I used CTRL_BREAK_EVENT instead of CTRL_C_EVENT because https://docs.microsoft.com/en-us/windows/console/generateconsolectrlevent says the following about CTRL_C_EVENT:

Generates a CTRL+C signal. This signal cannot be generated for process groups. If dwProcessGroupId is nonzero, this function will succeed, but the CTRL+C signal will not be received by processes within the specified process group.

Indeed, this change allows


system ("sleep 10")


to be interrupted.  But it also brings back the hanging behavior with Ctrl-C dwhen _run_test_suite_ is executing.  While Octave appears to be stuck, I can use the task manager to kill the cmd.exe that (I think) Octave is starting when processing doc strings for usage messages and then control will return to the Octave prompt.  So the question is, why does that use of cmd.exe hang but not the cmd.exe that is started to execute the "sleep" process?

I guess hanging the whole Octave process is worse than not being able to interrupt subprocesses?  So, while it would be best to make this work as it does now on POSIX systems, that will probably have to wait until after the release unless someone else has some insight and a fix.

John W. Eaton <jwe>
Group administrator
Thu 19 Apr 2018 06:04:43 AM UTC, comment #25: 

Ah, thanks for the reminder about blocked signals.

How about this patch for Unix systems?  I pushed on stable and merged with default.

http://hg.savannah.gnu.org/hgweb/octave/rev/78fb24bdd8bb

John W. Eaton <jwe>
Group administrator
Thu 19 Apr 2018 02:19:51 AM UTC, comment #24: 

Oops, copy-pasted without looking, it should have been obvious that was wrong. Here is the correct list of signals blocked by the sleep child process:


>> (find (fliplr (dec2bin (hex2dec ("0000000003817007"))) == "1")).'
ans =

    1
    2
    3
   13
   14
   15
   17
   24
   25
   26


Mike Miller <mtmiller>
Group Member
Thu 19 Apr 2018 02:00:29 AM UTC, comment #23: 

Yes, that is what's going on.


## run sleep at the bash command prompt
$ pgrep sleep
19590
$ grep Sig /proc/19590/status
SigQ:        3/63696
SigPnd:        0000000000000000
SigBlk:        0000000000000000
SigIgn:        0000000000000000
SigCgt:        0000000000000000

## run sleep at the octave command prompt
$ pgrep sleep
19855
$ grep Sig /proc/19855/status
SigQ:        3/63696
SigPnd:        0000000000000000
SigBlk:        0000000003817007
SigIgn:        0000000000000000
SigCgt:        0000000000000000


The SigBlk field shows that the following signal numbers are being blocked by the sleep process. Left as an exercise for the reader to turn the numbers into signal names.


>> (find (fliplr (dec2bin (hex2dec ("0000000003817007"))))).'
ans =

    1
    2
    3
    4
    5
    6
    7
    8
    9
   10
   11
   12
   13
   14
   15
   16
   17
   18
   19
   20
   21
   22
   23
   24
   25
   26


Mike Miller <mtmiller>
Group Member
Thu 19 Apr 2018 01:48:53 AM UTC, comment #22: 

Is Octave's new default signal blocking setup inherited by child processes? I think that might be the case. I am only able to kill a 'sleep' or a 'yes' process started from Octave by sending them a SIGKILL, the normal SIGINT and SIGTERM signals seem to be ignored.

It's possible the only reason emacs works is because emacs is complex enough that it's setting up its own signal handling and masking and unmasking the signals it wants to receive.

Mike Miller <mtmiller>
Group Member
Wed 18 Apr 2018 08:24:36 PM UTC, comment #21: 

If I do


system ("emacs")


then that opens up a new window and I'm able to use Ctrl-C in the Octave command window or at the octave-cli prompt to kill the Emacs process.  But it doesn't work with sleep.  WTF?

John W. Eaton <jwe>
Group administrator
Wed 18 Apr 2018 05:51:15 PM UTC, comment #20: 

Same results as Mike for 4.3.90, Ctrl+C does not work for subprocesses in either the CLI or GUI.

On 4.0.3, Ctrl+C worked in the CLI, but not in the GUI.

Test code was


system ("sleep 5");
<Ctrl+C>



Rik <rik5>
Group administrator
Wed 18 Apr 2018 05:23:56 PM UTC, comment #19: 

I can't kill any subprocess with Ctrl+C, neither in octave-cli nor in the gui.

Mike Miller <mtmiller>
Group Member
Wed 18 Apr 2018 05:17:31 PM UTC, comment #18: 


system ("sleep 10");


Mike Miller <mtmiller>
Group Member
Wed 18 Apr 2018 04:46:28 PM UTC, comment #17: 

What is a good test case for subprocesses on Linux?

I've tested the Ctrl+C fix on Windows with _run_test_suite_ and it works.

Rik <rik5>
Group administrator
Wed 18 Apr 2018 01:31:13 PM UTC, comment #16: 

Not mentioned here yet is bug #45654.  My first patch alone would have fixed that problem, but sometimes people do want Ctrl-C at the command prompt to interrupt subprocesses.  So I don't know exactly what to do about these issues.  We probably do need a way to allow a processes to be started in a separate process group, then that feature can be used to open external editor windows.

John W. Eaton <jwe>
Group administrator
Wed 18 Apr 2018 01:25:23 PM UTC, comment #15: 

I also pushed this additional change so that Octave will again interrupt subprocesses:

http://hg.savannah.gnu.org/hgweb/octave/rev/692fbde19871

This change has no effect on Windows systems because the kill function is not available.

John W. Eaton <jwe>
Group administrator
Wed 18 Apr 2018 09:13:39 AM UTC, comment #14: 

It works for me also (tested in Win-10)

Avinoam Kalma <avinoam>
Group Member
Wed 18 Apr 2018 01:50:38 AM UTC, comment #13: 

I pushed the following changeset on stable and merged with default:

http://hg.savannah.gnu.org/hgweb/octave/rev/4adeabc1bbfe

It seems to fix the problem for me.

John W. Eaton <jwe>
Group administrator
Tue 17 Apr 2018 11:08:04 PM UTC, comment #12: 

This problem seems to be an interaction with the cmd.exe subprocess that is started when doing things like running makeinfo to format docstrings.  I have a possible fix.  The idea is to simply set the global interrupt state for the interpreter in terminal_dock_widget::terminal_interrupt instead of using Qt signals and slots and ultimately calling


GenerateConsoleCtrlEvent (CTRL_C_EVENT, 0);


to generate an interrupt.  This approach works on my Debian system.  Ctrl-C at the command prompt still works.  I'll post a proper patch here after I have a chance to test it on Windows.

John W. Eaton <jwe>
Group administrator
Mon 16 Apr 2018 08:36:45 PM UTC, comment #11: 

@Rik:
Thanks for checking. I got the same results as you.
The only difference is that in 4.2.1, the second CTRL-C
crashes Octave (some way to abort...)

Avinoam Kalma <avinoam>
Group Member
Mon 16 Apr 2018 04:06:08 PM UTC, comment #10: 

Confirmed.  I can break use Ctrl+C to break a while (1) loop, but not to break the execution of _run_test_suite_.  I have changed the Summary message to indicate that there is some functionality, but not complete functionality.

Using Windows 4.3.90, and octave-cli.exe I see the following behavior


__run_octave_test_suite__
## Wait a moment for bitfcns.cc or bsxfun.cc to be running their tests.
## Type one Ctrl+C.
## Program seems to halt--there is no activity by octave in the Task Manager--
## but control is not returned to the Octave prompt.
## It seems to be waiting for further input.  At this point I can type
## characters and they are echoed to the terminal.  I can also hit <RETURN>.
## All of the input seems to be ignored.
## Type a second Ctrl+C.  The sequence '^C' is echoed to the terminal and
## Octave returns to the prompt.


Interesting things are that the first Ctrl+C is not echoed to the terminal, but is apparently swallowed and processed by something associated with Octave.  And it takes a second Ctrl+C to actually exit whatever intermediate state it is in and return to the prompt.

If I use the GUI the situation is worse.  The first Ctrl+C halts activity by Octave, as evidenced by zero activity in the Task Manager, but there is no way to get out of the intermediate state and return to the prompt.  Instead, each Ctrl+C is merely echoed as '^C'.

If I go back to Windows 4.2.1 and octave-gui.exe then it is roughly similar.  The first Ctrl+C halts Octave activity and moves it into a terminal state which accepts input.  The second Ctrl+C is echoed as '^C', but I get a warning "Press Ctrl+C again to abort".  I can type anything I want, but to get out of the hung state I eventually have to hit Ctrl+C which does abort Octave.

Rik <rik5>
Group administrator
Sat 14 Apr 2018 07:51:37 PM UTC, comment #9: 

@Philip: I'm not sure. This bug is a Windows only problem.
On Unix CTRL-C works well.
Bug #44485 seems to be on all platforms.

Avinoam Kalma <avinoam>
Group Member
Sat 14 Apr 2018 07:23:03 PM UTC, comment #8: 

Does this look a bit like bug #44485 ?
The underlying mechanism is IMO largely the same.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 14 Apr 2018 06:56:00 PM UTC, comment #7: 

@Hartmut: Thanks for your detailed checking

As you saw, you can try


test <octave_dir>\share\octave\4.3.90\etc\tests\libinterp\corefcn\bsxfun.cc-tst


when <octave_dir> is octave root directory.


Avinoam Kalma <avinoam>
Group Member
Sat 14 Apr 2018 06:04:12 PM UTC, comment #6: 

Yes, I can now confirm that the result of pressing Ctrl-C in the command window under Windows is somehow buggy compared to the behavior under Linux.
When running _run_test_suite_ from the command window:

  • under Linux: Ctrl-C stops the execution pretty soon at any time


  • under Windows (7, and also 10 if I remember right): It seems to me that the execution can only be stopped when I press the Ctrl-C keys at a time BETWEEN two consecutive tests (e.g. during the first 10 test cases in _run_test_suite_). When I press Ctrl-C during a long running test (e.g. bitfcns.cc-tst or bsxfun.cc-tst) then this does NOT stop the execution. Even worse, this results in the freezing of the command windows, it just never finishes this test then.


@Avinoam: Could you try to prepare a minimal test case for this Ctrl-C behavior under Windows? (Currently our observations are a bit vague, this probably makes it hard for other people to reproduce the problem.)

Hartmut <hardy>
Sat 14 Apr 2018 09:39:36 AM UTC, comment #5: 

@Hartmut (comment #1)

"while true end" works for me also.
Please try __run_test_suite__ in command window, and then press CTRL-C

Avinoam Kalma <avinoam>
Group Member
Fri 13 Apr 2018 07:40:33 PM UTC, comment #4: 

This works for me (Windows XP VM).

Rik <rik5>
Group administrator
Fri 13 Apr 2018 05:49:33 PM UTC, comment #3: 

In my Windows tests from comment #1 (where Ctrl-C worked fine) I only ever used this shortcut key in the "command window". I have never tried to use it in the gui editor window. (I didn't even know it's supposed to work there...)

Hartmut <hardy>
Fri 13 Apr 2018 05:43:43 PM UTC, comment #2: 

What happens if you undock the documentation window so that it is free floating?  Does it work then?  It might be a case of bug #53640 which was just fixed.

Rik <rik5>
Group administrator
Fri 13 Apr 2018 11:48:16 AM UTC, comment #1: 

It worked fine for me. Win7 and Win10. Using the GUI from the official Win64-installer for 4.3.90. I tested "while true end", and then Ctrl-C to stop it. No problems.

Hartmut <hardy>
Fri 13 Apr 2018 11:34:47 AM UTC, original submission:  


Checking version 4.3.90 on Win-10,
CTRL-C does not work in GUI mode, while it works fine
in CLI mode.

Can some confirm this?

Avinoam Kalma <avinoam>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by avinoam (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 group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-04-19 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2018-04-18 jwe StatusConfirmed Ready For Test
    2018-04-16 rik5 StatusWorks For Me Confirmed
        SummaryCTRL-C does not work in Windows GUI CTRL-C does not work in all instances when using Windows GUI
        Carbon-Copy- Added jwe
    2018-04-13 rik5 StatusNone Works For Me

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code