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

Submitted by:  Avinoam Kalma <avinoam>
Submitted on:  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

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)

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

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

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

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

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>
Project 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>
Project 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:

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

Yes, that is what's going on.

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.

Mike Miller <mtmiller>
Project Administrator
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>
Project Administrator
Wed 18 Apr 2018 08:24:36 PM UTC, comment #21:

If I do

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

Rik <rik5>
Project 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>
Project Administrator
Wed 18 Apr 2018 05:17:31 PM UTC, comment #18:
Mike Miller <mtmiller>
Project Administrator
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>
Project 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>
Project 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>
Project Administrator
Wed 18 Apr 2018 09:13:39 AM UTC, comment #14:

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

Avinoam Kalma <avinoam>
Project 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>
Project 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

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

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>
Project 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>
Project 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>
Project Member
Sat 14 Apr 2018 06:56:00 PM UTC, comment #7:

@Hartmut: Thanks for your detailed checking

As you saw, you can try

when <octave_dir> is octave root directory.

Avinoam Kalma <avinoam>
Project 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>
Project Member
Fri 13 Apr 2018 07:40:33 PM UTC, comment #4:

This works for me (Windows XP VM).

Rik <rik5>
Project 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>
Project 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>
Project 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)
  •  

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