bugGNU Octave - Bugs: bug #52876, interrupt with <Ctrl> C does...

 
 

bug #52876: interrupt with <Ctrl> C does not terminate octave during pause

Submitted by:  A.R. Burgers <arb>
Submitted on:  Sat 13 Jan 2018 11:37:00 AM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

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)

Sun 11 Feb 2018 06:34:00 PM UTC, comment #10: 

I think we live with the new behavior and see if it generates any complaints.  It doesn't seem bad to be compatibile with Python in this regard.

Rik <rik5>
Project Administrator
Fri 19 Jan 2018 01:22:53 AM UTC, comment #9: 

I said background, but I meant stopped / suspended, not running.

Mike Miller <mtmiller>
Project Administrator
Fri 19 Jan 2018 01:21:31 AM UTC, comment #8: 

One additional result of this change is that Octave now sleeps the full amount it was told to sleep, even when it is put into the background for more than the remaining time.

In Octave 4.2:

>> pause (5)
^Z
[1]+  Stopped                 octave-cli
$ ... wait around some time in the shell
$ fg
>> ## Octave's prompt returns immediately

Now Octave continues to sleep the full amount that the user requested only while Octave is active, elapsed time in the background state has no effect.

This may be considered better, just observing that this is a side effect coming from this change. This is also how Python behaves when it is put into the background in the middle of a call to time.sleep.

Mike Miller <mtmiller>
Project Administrator
Wed 17 Jan 2018 09:45:00 PM UTC, comment #7: 
John W. Eaton <jwe>
Project Administrator
Wed 17 Jan 2018 08:17:13 PM UTC, comment #6: 

Since the changeset from comment #4, Octave no longer cross-compiles for Windows on my Ubuntu 17.10.
The attached patch fixes the issue for me.

(file #42941)

Markus M├╝tzel <mmuetzel>
Project Member
Mon 15 Jan 2018 10:33:28 PM UTC, comment #5: 

Thanks for addressing this quickly, as I started digging into the issue and would have kept going.  I basically printed debug statements to std::cerr wherever there was octave_interrupt_state action.

I pulled the latest source and nothing has changed (an executing hunk of script breaks out, but not the sleeping pause).

octave:4> for i=1:10e8;
> x=1;
> end
^C
octave:4>
octave:4> pause()

octave:4>

Perhaps I'm not testing this correctly, but likely a timer computation issue.  (I can look debug on this end, if you like.) 

I read a lot of FIXME's near the octave_interrupt_state increments and tests.  This awake/poll/octave_quit approach to dealing with signals isn't good, but I understand it is the best that can be done right now.

My feeling is that Octave is a rather sophisticated interpretted computer language and, as such, it really requires a sophisticated interrupt system--one that is very solid and easy to use when it is debugged.  That is, spend some time coming up with a scheme that programmers really don't have to think too much about.  My initial thoughts on how to do that is Octave should have its own stack management and (possibly) memory management.  Octave sort of has the latter already.  What I mean by that is there should be

GLOBAL STACK
GLOBAL MEMORY
EXECUTION STACK
EXECUTION MEMORY

There must be some way in C to take control of the stack, e.g.,

https://stackoverflow.com/questions/1847053/how-to-get-address-of-base-stack-pointer

The idea is that before parsing and executing code, Octave would record the current location of the call-stack.  When parsing, executing, Octave would put any temporary heap variables (i.e., those that won't reside in global memory when done) into it's own sort of local heap.  Some of those entries may go to global memory (either immediately or eventually after the whole script has executed successfully).  Then, if a SIGINT comes along, it's simply a matter of stopping execution by rewinding the local call stack, freeing the local heap and jumping back to the Octave command line.  No checking octave-quit, no sleep/poll timers, etc.--fast and efficient.

Dan Sebald <sebald>
Mon 15 Jan 2018 09:44:27 PM UTC, comment #4: 

I checked in the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/6b3c78f84d3b

This change could probably be improved but at least it should allow pause to be interrupted.

John W. Eaton <jwe>
Project Administrator
Mon 15 Jan 2018 09:19:11 PM UTC, comment #3: 

The cntrl-C works when launching a script at command line.  I type cntrl-C, Octave closes and the bash shell line comes back.  No issues.

But you are right.  There's a bug in the cntrl-C from the Octave command line.  I was thinking it was simply a cosmetic issue of Octave not displaying the prompt, but in fact one keystroke is lost.  For example (no need for any code other than pause), in the following I type "x = 3" after the control-C during the pause:

octave:1> pause()


octave:1>  = 3
parse error:

  syntax error

>>>  = 3

I wonder how this went unnoticed.

Issue confirmed.

Dan Sebald <sebald>
Mon 15 Jan 2018 08:59:59 PM UTC, comment #2: 

regarding the command line prompt, I executed the lines from my example in a script, say ctrl.m and then ran octave ctrl.m.
Hence I don't expect and don't get any command line prompt.

<Ctrl c><Enter> has the same effect as <Ctrl c><Ctrl d> for me too, ends execution. On octave-4.2.1 the <ctrl c> on its own already ends the script. This is a change in behavior between dev and 4.2.1, but whether this qualifies as regression, I don't know.

A.R. Burgers <arb>
Sun 14 Jan 2018 08:10:26 PM UTC, comment #1: 

This works for me on the latest development version.  I will note that it doesn't appear to work because the "octave:#>" doesn't appear after typing cntrl-C, but if I hit the return key after the cntrl-C it is clear that the command line is responsive again and, also, the title of the plot still indicates "interation 1".  This is the same behavior for all graphics toolkits.  (There may be older versions in which cntrl-C didn't work for Qt and/or fltk, but did work for gnuplot.  I sort of remember such issues; had to do with some tricky thread interaction when plotting.)

Dan Sebald <sebald>
Sat 13 Jan 2018 11:37:00 AM UTC, original submission:  

Consider this script:

version = version
hg_id = __octave_config_info__.hg_id
for i = 1:3
    plot(1:10)
    title(sprintf('iteration %d', i));
    pause
end

hg_id = bccb203494f6+

<Ctrl C> during pause does not terminate the program, in 4.2.1 it does.

<Ctrl C><Ctrl D> does terminate the program.

<Ctrl D> alone resume execution after the pause, as in 4.2.1

A.R. Burgers <arb>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #42941:  bug52876_nanosleep.patch added by mmuetzel (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by arb (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-02-11 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2018-01-17 mmuetzel Attached File- => Added bug52876_nanosleep.patch, #42941
    2018-01-15 jwe StatusNone => Ready For Test

    Back to the top


    Powered by Savane 3.5