bugGNU Octave - Bugs: bug #44912, Ctrl+C doesn't interrupt and...


bug #44912: Ctrl+C doesn't interrupt and causes SIGABRT at exit

Submitter:  Pantxo Diribarne <pantxo>
Submitted:  Thu 23 Apr 2015 10:16:51 PM UTC
Category:  GUI Severity:  5 - Blocker
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Mon 04 May 2015 03:31:32 PM UTC, comment #33: 

As far as I can see, following fix in bug #44968, everything is working fine so this report can be closed, unless someone else still experiences a problem.


Guillaume <gyom>
Fri 01 May 2015 03:19:52 PM UTC, comment #32: 

@Guillaume: Now that bug #44968 (Ctrl+C shortcut) has been fixed,  do you still experience a problem?  Or can this report be closed as well?

Rik <rik5>
Group administrator
Mon 27 Apr 2015 07:09:36 PM UTC, comment #31: 

OK, clipboard copy noted... yes, that shouldn't affect the issue here.

Furthermore, Guillaume tested the repository as far back as early February (https://savannah.gnu.org/bugs/?44912#comment26) and found Cntrl-C is not working then already.  I think that openSUSE system is really testing thread behavior somehow.  What's interesting is that the Cntrl-C problem is primarily in the GUI Qt realm.  The question is how to determine why the terminal_interrupt() slot isn't being called/signaled.  We know graphical objects and most of the GUI is run in the main thread of the process.  However, where is the keyboard Qt code executing from?  Same thread?  I'll look that over sometime in the next couple days and see if there are some things Guillaume can test on openSUSE to determine what is happening.

Dan Sebald <sebald>
Mon 27 Apr 2015 01:56:29 PM UTC, comment #30: 

Dan, the if-construct really seems to copy empty text (i.e. clearing the clipboard) when the copy shortcut is not Ctrl-C. I will prepare a cset fixing that. However, this should not affect the issues discussed here.
The initialization is actually done in notice_settings. The related signal is emitted at start-up for loading the settings in all dock widgets.

Torsten Lilge <ttl>
Group Member
Mon 27 Apr 2015 01:02:39 PM UTC, comment #29: 

From what I can see, yes, Ctrl-C is the copy shortcut - I attach a number of screenshots of the preferences and the Edit menu (of the Command window and of the editor).

Guillaume <gyom>
Mon 27 Apr 2015 05:11:36 AM UTC, comment #28: 

Guillaume, could you please check in the settings that Ctrl-C is really configured as copy shortcut in the main window?

Torsten Lilge <ttl>
Group Member
Mon 27 Apr 2015 04:46:33 AM UTC, comment #27: 

I applied Dan's patch which works for most systems here (http://hg.savannah.gnu.org/hgweb/octave/rev/46fb763e5f3a).  I'm leaving the bug Open and "In Progress" in case something else can be done for Guillaume's system.

Rik <rik5>
Group administrator
Sun 26 Apr 2015 09:18:24 PM UTC, comment #26: 

I tried to revert changeset bd1369a2a651 only (using hg diff --reverse) and, without it, Ctrl-C works when used for copy but still doesn't work as an interception.

So there might be two different issues, one related to bd1369a2a651 (for copy) and one elsewhere (for cancel). It seems that patch from comment #17 should anyway be applied as it fixes the cancel issue for most (but me).

Guillaume <gyom>
Sun 26 Apr 2015 05:20:14 PM UTC, comment #25: 

OK, thanks.  Neither cntrl-C nor copy is working for you.  That is likely not a thread issue on your system.  Perhaps we should apply changeset


and open a new bug report so that discussion for the behavior you are seeing is separate from the this bug-report thread.

I do see a couple lines of investigation for this changeset


but I'll let T cogitate about those.

First, might it be that this conditional construct

  if (text.isEmpty () && ! extra_interrupt)
    emit interrupt_signal ();

should be more along the lines

  if (text.isEmpty ())
    if  (! extra_interrupt)
      emit interrupt_signal ();

Also, I don't see in that changeset anywhere that the new variable _extra_interrupt is directly initialized anywhere.  That doesn't meant it isn't initialized indirectly, but the place that _extra_interrupt is set is via QTerminal::notice_settings() and that is a slot.  Perhaps that slot is called when the QTerminal is constructed, but like I said I'll let someone else first look more closely at that.

Dan Sebald <sebald>
Sun 26 Apr 2015 02:27:03 PM UTC, comment #24: 

If I remove teh line

moveToThread (main_thread);

from the octave_qt_link constructor, interrupts work as expected for me.  I don't know whether this causes other problems.

John W. Eaton <jwe>
Group administrator
Sun 26 Apr 2015 11:04:19 AM UTC, comment #23: 

With your patch, "focus in/out" seems to be displayed appropriately, each time the focus leaves the Command Window.

I don't see anything when typing Ctrl-C. It also seems that nothing is copied to clipboard when typing it after highlighting some text (in the Command Window - it is fine with the Editor): i.e. Ctrl-C feels like a no-op.

Guillaume <gyom>
Sun 26 Apr 2015 07:22:32 AM UTC, comment #22: 

If the actions used for copying and interrupting are related in some way, it might also be of interest whether Ctrl-C or any other shortcut is used for the copy action. Both cases are handled differently since cset bd1369a2a651.

Torsten Lilge <ttl>
Group Member
Sun 26 Apr 2015 01:01:14 AM UTC, comment #21: 

Here's another patch to try on openSUSE.  It isn't much different, just prints out information about the focus and any extra shortcut key.  The Cntrl-C is associated with a QAction called _interrupt_action, which is added to the QTerminal.  Anyway, please let me know of any output you see when typing Cntrl-C and focusing in and out of the terminal window.

(file #33789)

Dan Sebald <sebald>
Sat 25 Apr 2015 11:52:49 PM UTC, comment #20: 

"If it's a peculiarity of my system (virtual machine, openSUSE 13.2, one CPU) or some system configuration to distinguish between copy and interuption then maybe the priority can be lowered."

I asked because your system seems like a good one for revealing the intricacies of threads.  I'm sure there are plenty of people who would experience the same as part of a release.

The fact you aren't seeing the message indicates that the QTerminal::interrupt_signal() isn't even being emitted.  So the hypothesis that the signal is being queued doesn't hold water.  On your system, the Cntrl-C is not making its way to the terminal.  That, or your system configuration is routing OS signal differently.  Let me think about this one for a bit--there are a lot of different "terminal_interrupt" signal/slot variations to decipher.

Dan Sebald <sebald>
Sat 25 Apr 2015 10:43:02 PM UTC, comment #19: 

This is the changeset that causes it to fail for me:


I see the same behavior as noted in comment #14.  Interrupting readline in the command window doesn't work after applying that change.

John W. Eaton <jwe>
Group administrator
Sat 25 Apr 2015 10:01:57 PM UTC, comment #18: 

With a clean repository (and 'make clean') and latest patch, I don't see any message being displayed when typing Ctrl-C in the GUI.

I've also just checked that it works fine with Octave 3.8.2 as installed on my system (openSUSE 13.2).

If it's a peculiarity of my system (virtual machine, openSUSE 13.2, one CPU) or some system configuration to distinguish between copy and interuption then maybe the priority can be lowered.

Guillaume <gyom>
Sat 25 Apr 2015 07:47:55 PM UTC, comment #17: 

Well, the octave_qt_link affinity should go back to GUI thread.  Got that much.

I suspect that the openSUSE configuration/Qt-behavior is showing up again in a different spot.  That is, the interrupt signal could possibly be queued on that system.

Let's confirm something on that system.  In the attached patch I've simply printed out when the GUI terminal window emits its interrupt signal (that's Qt signal, not OS signal).  Please apply that to a clean repository and report what you see when hitting Cnrtl-C in the GUI after this change.  This will tell us whether the issue is Cnrtl-C not being acknowledged by the GUI or if it's that "interrupt terminal" is not making its way through octave_qt_link.

(file #33788)

Dan Sebald <sebald>
Sat 25 Apr 2015 02:39:43 PM UTC, comment #16: 

Linking bug #44751 to this one since they will both need to be solved at the same time.

Rik <rik5>
Group administrator
Sat 25 Apr 2015 02:33:11 PM UTC, comment #15: 

Can other testers report whether Dan's patch works?  The count so far is 2 working / 1 non-working.

@Guillaume: After applying Dan's patch, did you do a 'make clean' just to make sure that there was nothing left over from a previous build?  Also, what distribution and version of Linux are you using?  There might be something in that as well.

Rik <rik5>
Group administrator
Sat 25 Apr 2015 01:08:10 PM UTC, comment #14: 

Here is what I observe using latest dev version (including Dan's last patch):

  • Octave with "--no-gui": Ctrl-C behaves appropriately and I can break "pause (5)" or script like in comment #5. Importantly it also stops and start a new line as described in comment #3.

  • with the GUI: Ctrl-C does not interrupt "pause (5)" or script #5 and is ineffective at cancelling a line in progress:

>> for i=1:10

With the code above, there is no way to cancel it and you either have to execute it ("endif") or quit Octave.

Guillaume <gyom>
Sat 25 Apr 2015 04:52:10 AM UTC, comment #13: 

@Dan: The patch fixes up the Ctrl+C handling.  I guess you should forward the patch to bug #44751 for testing as well.

Rik <rik5>
Group administrator
Sat 25 Apr 2015 04:43:16 AM UTC, comment #12: 

OK, it must be that all signals are not handled properly.  Hitting Cntrl-C three times without the program responding issues an abort to the program, which also isn't handled as explained by the exit message.

In the changeset


is a lot of code hunks not even touched by the example, so it must be this one change:

+  // Move this link object affinity to the same thread as the
+  // interpreter to ensure signals/slots to the GUI are queued.
+  moveToThread (main_thread);

and if I recall correctly, the queuing of signals wasn't the problem ultimately.  Let's move that back and see what happens with the attached changeset.

If this works, we'll ask that this bug


be checked again, but I don't think it should be a problem.

Thanks for bisecting.

(file #33780)

Dan Sebald <sebald>
Fri 24 Apr 2015 04:50:02 PM UTC, comment #11: 

The cset which introduced the problem is

20091:89d843d6de14 Add mutex lock to shutdown confirmation for proper thread timing (bug #44751) by Dan Sebald.

Dan is already on the CC list for this bug so hopefully he can investigate.

Rik <rik5>
Group administrator
Fri 24 Apr 2015 04:15:19 PM UTC, comment #10: 

Cool.  I'm starting with 9a2d8b1f931e as good and tip as bad (~7 tests).

Rik <rik5>
Group administrator
Fri 24 Apr 2015 04:11:30 PM UTC, comment #9: 

If you haven't started yet, 9a2d8b1f931e also appears to be good.

John W. Eaton <jwe>
Group administrator
Fri 24 Apr 2015 03:59:34 PM UTC, comment #8: 

I've already done a couple of steps.  For me, the current revision is bad and 19755f4fc851 was good.  Starting with those might save you a little time.

John W. Eaton <jwe>
Group administrator
Fri 24 Apr 2015 03:52:06 PM UTC, comment #7: 

@jwe: I can do the bisecting as that is rather mindless work.  If you have free time it might be better spent on bug #44862 and bug #44864.

Rik <rik5>
Group administrator
Fri 24 Apr 2015 03:30:21 PM UTC, comment #6: 

It is only recently that it stopped working.

Unless someone else wants to do it, I could bisect to find where it started failing.

John W. Eaton <jwe>
Group administrator
Fri 24 Apr 2015 03:06:53 PM UTC, comment #5: 

@Mike: It's true that we may not have been able to break out of system calls in the past.  But we were able to break out of Octave m-files and this has also disappeared.

Sample code in tst_for.m

N = 1e5;
for i = 1:N
  y(i) = sin (rand (1));

This takes about 5 seconds ond my computer and I can't use Ctrl+C to stop it.  This worked in 3.8.2.

(file #33771)

Rik <rik5>
Group administrator
Fri 24 Apr 2015 01:30:13 PM UTC, comment #4: 

That was confusing, I meant SIGABRT is raised by the abort function, which can be called by user code, or by assert, std::terminate, and the other examples given.

Mike Miller <mtmiller>
Group Member
Fri 24 Apr 2015 01:28:04 PM UTC, comment #3: 

Rik, do you mean that Ctrl+C used to actually interrupt the pause? I see that in 3.8.2, I don't remember when that worked or stopped working or what the status of that has been (bug #37672 is still open).

Dan, SIGINT is the signal sent by Ctrl+C. SIGABRT is typically raised by the terminate function, which is called in the standard library by the abort function, std::terminate (which is called for e.g. uncaught exceptions), or by certain errors in the memory management library (double free, corrupted memory tables, etc).

Actually I think this is unrelated to the pause function. Ctrl+C is supposed to interrupt the current line and start a new line (at least it does in the terminal, used to in the GUI). It doesn't do that anymore. I think something has broken Octave's normal Ctrl+C handler. Just try hitting Ctrl+C at the prompt. One Ctrl+C and exiting Octave is ok. Two is ok. Three causes the SIGABRT.

Mike Miller <mtmiller>
Group Member
Fri 24 Apr 2015 06:38:41 AM UTC, comment #2: 

I noticed this not working the other day, but I recalled (maybe incorrectly) something about a Preferences setting controling the Cntrl-C behavior (is it "interrupt", or is it "copy").  I couldn't find such a setting so paid no more thought to it.

In any case, that warning message is issued in main.in.c:

          while (true)
              WAITPID (gui_pid, &status, 0);

              if (caught_signal > 0)
                  int sig = caught_signal;

                  caught_signal = -1;

                  kill (gui_pid, sig);
              else if (WIFEXITED (status))
                  retval = WEXITSTATUS (status);
              else if (WIFSIGNALLED (status))
                  std::cerr << "octave exited with signal "
                            << WTERMSIG (status) << std::endl;

My guess would be simply that the control-C interrupt signal is being ignored and, consequently, the command interpreter not interrupted.  Thus, when the main routine checks the PID status of the gui, i.e., WAITPID (gui_pid, &status, 0);, at the time of exit it finds that there was an unhandled signal.  If I type SIG on my system:


signal 6 is ABRT.  I'm pretty sure that what cntrl-C triggers.

Somewhere along the way, the GUI lost the ability to respond to the ABRT signal.

Dan Sebald <sebald>
Fri 24 Apr 2015 05:04:56 AM UTC, comment #1: 

Confirmed.  And this used to work at some point in the GUI.

Rik <rik5>
Group administrator
Thu 23 Apr 2015 10:16:51 PM UTC, original submission:  

I am currently unable to interrupt e.g. "pause (5)" using Ctrl+C. Octave returns to prompt after 5 seconds, but when I exit I see the "octave exited with signal 6" message.
Steps to reproduce:

$ ./run-octave -f
pause (5) ## now press Ctrl+C several times

In case it matters, I use the default set of shortcutsand I am at "hg summary":

parent: 20119:f46f6d906654 tip
 Avoid unnecessarily calling graphics callbacks in FLTK.

Pantxo Diribarne <pantxo>
Group Member


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

Attach Files:

Attached Files
file #33810:  preferences.png added by gyom (53KiB - image/png)
file #33811:  copypaste_editor_1.png added by gyom (34KiB - image/png)
file #33813:  copypaste_editor_2.png added by gyom (26KiB - image/png)
file #33789:  print_focus-djs2015apr25.diff added by sebald (2KiB - application/octet-stream)
file #33788:  print_interrupt_emit-djs2015apr25.diff added by sebald (1KiB - application/octet-stream)
file #33771:  tst_for.m added by rik5 (53B - text/x-objcsrc)


   bug dependencies.

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by gyom (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 sebald (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by pantxo (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 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-05-04 rik5 StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2015-04-27 gyom Attached File- Added preferences.png, #33810
        Attached File- Added copypaste_editor_1.png, #33811
        Attached File- Added copypaste_commandwindow.png, #33812
        Attached File- Added copypaste_editor_2.png, #33813
    2015-04-27 rik5 StatusPatch Submitted In Progress
    2015-04-26 sebald Attached File- Added print_focus-djs2015apr25.diff, #33789
    2015-04-25 sebald Attached File- Added print_interrupt_emit-djs2015apr25.diff, #33788
    2015-04-25 rik5 Dependencies- Depends on bugs #44751
    2015-04-25 rik5 StatusConfirmed Patch Submitted
    2015-04-25 sebald Attached File- Added octave-octave_qt_think_thread_affinity-djs2015apr24.patch, #33780
    2015-04-24 rik5 Attached File- Added tst_for.m, #33771
    2015-04-24 mtmiller Severity3 - Normal 5 - Blocker
        SummaryCtrl+C doesn\'t interrupt and causes SIGABORT at exit Ctrl+C doesn't interrupt and causes SIGABRT at exit
    2015-04-24 rik5 StatusNone Confirmed
        SummaryCtrl+C doesn\'t interrupt and provoques SIGABORT at exit Ctrl+C doesn't interrupt and causes SIGABORT at exit

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code