bugGNU Octave - Bugs: bug #51658, fatal error does not leave Octave...

 
 

bug #51658: fatal error does not leave Octave resulting in unresponsive command line

Submitter:  Dan Sebald <sebald>
Submitted:  Fri 04 Aug 2017 05:13:18 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
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

Sun 03 Mar 2019 05:50:59 PM UTC, comment #9: 

The issue with Ctrl+C not being passed to the pager when 'less' is in "follow output" mode is a separate bug, I can reproduce that, please report that separately.

When 'less' is behaving normally, not in "follow output" mode, it normally ignores SIGINT, so Ctrl+C is supposed to do nothing.

The original issue here seems fixed.

Mike Miller <mtmiller>
Group Member
Sun 03 Mar 2019 05:41:35 PM UTC, comment #8: 

Regarding the lag.  I'm fine with the lag, but the odd part is the break in the text.  There is a ^C followed by text that is discontinuous from the text before the ^C.

I'm running CLI:


sebald@ ~ $ /usr/local/src/octave/octave/build1/run-octave
octave:1> more on
octave:2> y = 1:1e7


Here's what I'm seeing


         29         30         31         32         33         34         35

 Columns 36 through 42:
warning: broken pipe


I find that strange, but this actually could be a pager issue on its own--I suppose I should investigate the pager outside of Octave.

But I've just come across a bigger issue, which I think can be summed up as "interrupting doesn't leave pager", which may be related to the original issue.

Try the same bit of code:


octave:6> more on
octave:7> y = 1:1e7


and hit Cntrl-C somewhere when it is displaying:


 Columns 36 through 42:
-- less -- (f)orward, (b)ack, (q)uit


Octave is still in the pager, when maybe it shouldn't be.  Perhaps there is some utility to being able to look at the output, even though the output isn't complete.  However, the issue is that the pager can do something that requires a Cntrl-C and maybe the Cntrl-C no longer works in the pager?

While still in the pager, type <Shift>-F, which means to keep moving (pressing) f indefinitely:


[snip]
 Columns 1259567 through 1259573:

    1259567    1259568    1259569    1259570    1259571    1259572    1259573

 Columns 1259574 through 1259580:

    1259574    1259575    1259576    1259577
Waiting for data... (interrupt to abort)


Cntrl-C doesn't work at this point.  (If there is a key sequence for abort, I don't know it.)  So, at this point octave is hung.

Repeat the above sequence without pressing Cntrl-C (use y=1:1e6 if you like), and Cntrl-C still works in the pager after having pressed <SHift>-F.

Anyway, it seems to me if Cntrl-C would also break out of the pager this problem would be solved.

Dan Sebald <sebald>
Sun 03 Mar 2019 03:34:55 PM UTC, comment #7: 

@Dan: Are you running the GUI or the CLI?  Also, the original report mentioned the pager, but the pager has been disabled by default now for some time ('more off').


To test I used the CLI, but with Qt libraries linked in


run-octave -f
y = 1:1e6
<Ctrl+C>


I think the little bit of excess output you see on stdout is simply time lag between typing <Ctrl+C> and having the interrupt routines fire.  It doesn't particularly bother me.

The original bug was about Octave becoming unresponsive which has been fixed.  You could file a new bug about updating the Octave history number after command evaluation has finished, rather than after Octave has fully returned a prompt to the user.

Rik <rik5>
Group administrator
Sun 03 Mar 2019 09:53:01 AM UTC, comment #6: 

Wait, there are still a couple things about this, but maybe these should go to a different bug report.  I'm not sure I'd call these bugs; maybe the second one.  Anyway, there is still some text that comes out of the pager after the ^C appears.  It's a hunk of ascii output, except its from down the line with what looks like about a lines worth of characters dropped:


octave:1> y = 1:10000000
[snip]
 Columns 95824 through 95830:

      95824      95825      95826      95827      95828      95829      95830

 Columns 95831 through 95837:

  ^C    95850      95851

 Columns 95852 through 95858:


octave:1>


I'm not sure how that could come about.

The second item is the octave line number.  It comes back as 1 when I think technically it should be 2.  y is valid:


octave:1> who
Variables visible from the current scope:

y


and all I did was break out of displaying the result.  Perhaps it is a different story if breaking out of the code portion of the evaluation.  The code hasn't been fully executed in that case.  However, in this case, the code evaluation has presumably completed.

Dan Sebald <sebald>
Sun 03 Mar 2019 07:25:20 AM UTC, comment #5: 

Cool.  Marking as fixed and closing report.

Rik <rik5>
Group administrator
Sun 03 Mar 2019 07:14:52 AM UTC, comment #4: 

No I can't.  I suppose it was fixed along with bug #50373 being changed so that multiple cntrl-C is no longer used.  The display breaks out immediately with no crash.  Also, upon entering

y = 1:10000000

the numbers start appearing immediately in the terminal window.  There is no longer a big delay for presumably filling up the pager buffer.  Nice!

Dan Sebald <sebald>
Sun 03 Mar 2019 06:02:10 AM UTC, comment #3: 

@Dan: This bug is 18 months old.  Can you still reproduce it with either 5.1.0 or the development version?

Rik <rik5>
Group administrator
Sat 05 Aug 2017 07:13:23 PM UTC, comment #2: 

(just a little bump for #50373: "consider disabling "Press Control-C again to abort")

Ceral Paquet <octavebugs>
Fri 04 Aug 2017 11:43:17 PM UTC, comment #1: 

There is definitely some weirdness going on.  Using the CLI, I can hit Ctrl+C 3 times which generates the message about a fatal error and saving of workspace variables.  However, I am still within the pager.  If I then type 'q' to leave the pager, I find myself at Octave command line rather than the shell command line.  And everything is fine.  I can execute more commands, etc.

Rik <rik5>
Group administrator
Fri 04 Aug 2017 05:13:18 PM UTC, original submission:  

If I run some command that dumps a lot of text to the pager, hitting cntrl-C doesn't immediately break.  So, continue hitting cntrl-C and the following happens:


octave:1> y = 1:10000000
[takes a moment then pager starts scrolling]
 Columns 57086 through 57092:

      57086      57087      57088      57089      57090      57091      57092^Cfatal: caught signal Interrupt -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave:1> ^Coctave:1>
octave:1>
octave:1> z = 1
octave:2>
octave:2> who
octave:3>


It appears the line counter is advancing as normal.  Maybe it is just the pager output that is broken at this point.  Is hitting cntrl-C supposed to result in a fatal error?  Or just break out of the pager?

Dan Sebald <sebald>

 

(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 octavebugs (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by sebald (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-03 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2017-08-04 rik5 CategoryNone Interpreter
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code