bugGNU Octave - Bugs: bug #51209, unwind_protect_cleanup does not...

 
 

bug #51209: unwind_protect_cleanup does not work if CTRL-C pressed

Submitter:  None
Submitted:  Fri 09 Jun 2017 06:58:48 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 4.2.1
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 16 Jun 2017 04:52:32 AM UTC, comment #7: 

Verified the patch.  Marking as fixed and closing report.

Rik <rik5>
Group administrator
Thu 15 Jun 2017 11:41:56 PM UTC, comment #6: 

Rik: thanks for bisecting.  I know that is not always easy, especially over wide ranges of history.

I checked in the following changeset on stable and merged with default:

http://hg.savannah.gnu.org/hgweb/octave/rev/fecca33388f7

John W. Eaton <jwe>
Group administrator
Thu 15 Jun 2017 04:15:08 PM UTC, comment #5: 

I asked about this on the Octave Maintainer's list and the opinion was that this is a regression in behavior and should be changed back to executing the unwind_protect_cleanup body if Ctrl+C is used.

The changeset which introduced the new behavior is


parent: 20651:b70cc4bd8109
 begin removal of global error_state variable



Rik <rik5>
Group administrator
Sat 10 Jun 2017 05:14:48 AM UTC, comment #4: 

Thanks maintainer.
By the way, I found that many Octave's function files use the "unwind_protect" statement. For exmaple, "ginput.m" use it to restore the original callbacks, "fileread.m" use it to "fclose" the file, and so on.
Since the behavior of this statement affects many Octave's functions, maybe it is a little difficult to decide which behavior is desired.

Anonymous
Sat 10 Jun 2017 03:04:40 AM UTC, comment #3: 

Confirmed.  I agree that I'm not sure which behavior is desired.  In one sense, Ctrl-C is supposed to interrupt whatever calculation is being done and return immediately to the command prompt.  That makes it reasonable to not execute the cleanup block.  However, Octave used to do this so why shouldn't the same behavior continue.  I'll post something about this on the Octave-Maintainer's list to see how this should be handled.

Rik <rik5>
Group administrator
Sat 10 Jun 2017 02:37:46 AM UTC, comment #2: 

For example,

unwind_protect
  while(1) end
  # or pause(1000);
  # or some other long codes
unwind_protect_cleanup
  disp('a');
  # or some other codes
end

and press CTRL-C when the codes in "unwind_protect" block is running.
In Octave 4.0.3 the 'a' will be displayed, but recently I just noticed that in Octave 4.2.1 the 'a' will NOT be displayed.


This just happens in the case of pressing CTRL-C.
Otherwise, no matter whether there is error in "unwind_protect" block, no matter in Octave 4.0.3 or 4.2.1, the 'a' will always be displayed, just as the document says.

Anonymous
Sat 10 Jun 2017 01:56:37 AM UTC, comment #1: 

Could you post some example code that reproduces the issue?

Rik <rik5>
Group administrator
Fri 09 Jun 2017 06:58:48 AM UTC, original submission:  

In Octave 4.0.3, unwind_protect_cleanup block will run if CTRL-C is pressed when unwind_protect block is running.
But in Octave 4.2.1, unwind_protect_cleanup block will NOT run if CTRL-C is pressed when unwind_protect block is running.

I'm not sure whether this is a bug, since the document in The unwind_protect Statement does not mention the behavior if CTRL-C is pressed.

Anonymous

 

(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 jwe (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by None (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 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-06-16 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2017-06-15 jwe StatusConfirmed Ready For Test
    2017-06-15 rik5 Carbon-Copy- Added jwe
    2017-06-10 rik5 StatusNeed Info Confirmed
    2017-06-10 rik5 CategoryNone Interpreter
        Item GroupNone Regression
        StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code