bugGNU Octave - Bugs: bug #52750, Ctl-C stops debugging when used...

 
 

bug #52750: Ctl-C stops debugging when used only to stop long output when more off

Submitter:  Marshall <marsian>
Submitted:  Wed 27 Dec 2017 04:06:34 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Marsian Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 30 Aug 2018 08:57:29 PM UTC, comment #13: 

Thanks for checking.  I re-tested and it does seem to work.  Closing report.

Rik <rik5>
Group administrator
Thu 30 Aug 2018 07:58:44 PM UTC, comment #12: 

This seems to be fixed in 4.4.1

Marshall <marsian>
Sat 13 Jan 2018 01:20:16 AM UTC, comment #11: 

Just to track what is going on I added


+    std::cerr << "debug_mode: " << debug_mode << std::endl;


in to reset_debug_state().  First, it is getting called for every single function evaluation which seems excessive.  I thought reset_debug_state() would only be called when there had been a change to the debug state such as adding a breakpoint or using dbquit.  Sample session below.


octave:2> x = 1
debug_mode: 0
x =  1
octave:3> y = 2
debug_mode: 0
y =  2
octave:4> x + y
debug_mode: 0
ans =  3


And as expected, the problem is that debug_mode is not reset because there are still breakpoints outstanding.


octave:1> diary on
debug_mode: 0
octave:2> dbstop sind
debug_mode: 1
ans =  31
octave:3> sind (1)
stopped in /home/rik/wip/Projects_Mine/octave-dbg/scripts/elfun/sind.m at line 31
31:   if (nargin != 1)
debug> dbnext
stopped in /home/rik/wip/Projects_Mine/octave-dbg/scripts/elfun/sind.m at line 35
35:   I = x / 180;
debug> dbquit
debug_mode: 1

recovering
debug_mode: 1
ans =  0.017452



Rik <rik5>
Group administrator
Sat 13 Jan 2018 01:16:09 AM UTC, comment #10: 

This seems real.  The patch for this was in pt-eval.cc and in the function visit_statement.


        catch (const octave::interrupt_exception&)
          {
            // If we are debugging, then continue with next statement.
            // Otherwise, jump out of here.

            if (debug_mode)
              interpreter::recover_from_exception ();
            else
              throw;
          }


But the dbquit function makes use of exceptions to return to the prompt.


{
  if (! Vdebugging)
    error ("dbquit: can only be called in debug mode");

  if (args.length () != 0)
    print_usage ();

  Vdebugging = false;

  octave::tree_evaluator::reset_debug_state ();

  octave_throw_interrupt_exception ();

  return ovl ();
}


Maybe reset_debug_state isn't resetting the state?

Rik <rik5>
Group administrator
Fri 12 Jan 2018 08:13:51 PM UTC, comment #9: 

Re-opening the bug.  "dbquit" no longer quits, but does something more akin to "dbcont".

Sample code:


dbstop ls
ls /usr/bin
dbnext 3      # just to execute a few things
dbquit


Result is that execution continues and the very long /usr/bin directory listing is sent to screen.

Rik <rik5>
Group administrator
Fri 12 Jan 2018 12:49:33 AM UTC, comment #8: 

Did this make it so that dbquit or the gui stop debugging button doesn't actually stop execution anymore?

Marshall <marsian>
Fri 12 Jan 2018 12:23:54 AM UTC, comment #7: 

Works great.

Marshall <marsian>
Wed 10 Jan 2018 08:43:47 PM UTC, comment #6: 

I pushed the following changeset:

  http://hg.savannah.gnu.org/hgweb/octave/rev/466e2aab871b

This seems to fix the problem for me.

John W. Eaton <jwe>
Group administrator
Fri 29 Dec 2017 05:32:21 AM UTC, comment #5: 

Okay, confirmed with your test code from commend #4.  This was on a Linux machine so I'm changing the Operating System to Any.  I was also using dev code so the issue is still present.

Rik <rik5>
Group administrator
Fri 29 Dec 2017 01:37:31 AM UTC, comment #4: 



%debug_on_interrupt (1)
more off
function f()
    disp((1:1000000).')
endfunction

dbstop f
f()

dbstep
% press ctl-c


debug_on_interrupt(1) doesn't help here, as it doesn't stop the output immediately on first ctl-c, and pressing ctl-c twice stops debugging printing immediately.

Marshall <marsian>
Fri 29 Dec 2017 12:19:41 AM UTC, comment #3: 

Could you post some code that we could use to reproduce the effect?

Judging only by what is reported, you might try 'debug_on_interrupt (1)'.  It is a hack, but when you use Ctrl+C it will go in to debug mode which is where you want to be anyways, rather than returning to the command prompt.

Rik <rik5>
Group administrator
Thu 28 Dec 2017 09:02:48 PM UTC, comment #2: 

I would be OK with either pausing or skipping/stopping the text output. I only really expect skipping/stopping text just as done at the command line when not debugging.

Ctl-S and Ctl-Q didn't do anything in Windows. In Linux, Ctl-Q is assigned to quit octave, and when it works has worse side effects, during debugging with long text output, ctl-Q didn't do anything until after ctl-C stopped the text output (and then it quit octave).

I tested in matlab, and Ctl-C works to stop the text output during debugging without ending the debugging session.

Marshall <marsian>
Thu 28 Dec 2017 05:33:51 PM UTC, comment #1: 

Do you want to merely pause the text output, or skip it altogether? (= silence it)

For the former, I think Qtrl-S (pause) and Qtrl-Q (resume) also work in Windows.

I have no access to Matlab ATM to check if Ctrl-C silences long output listings; then again Matlab echoes long listing very very fast so it might be hard to assess the effect of Ctrl-C there.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 27 Dec 2017 04:06:34 PM UTC, original submission:  

If I have 'more off', and then during debugging I run a command that displays an excessive amount of effort, I am used to pressing ctl-c to stop the output (I believe matlab does this). However besides only stopping the output to the console, it also exits debugging mode. It should only stop the text output, and not stop debugging (unless stopped at the command line and waiting?). I've seen this in 4.2.1 and the dev version.

Marshall <marsian>

 

(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 (Posted a comment)
  • -email is unavailable- added by marsian (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 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-08-30 rik5 StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2018-01-12 rik5 StatusFixed In Progress
        Open/ClosedClosed Open
    2018-01-12 jwe StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2018-01-10 jwe CategoryGUI Interpreter
    2018-01-10 jwe StatusConfirmed Ready For Test
    2017-12-29 rik5 StatusNeed Info Confirmed
        Release4.2.1 dev
        Operating SystemMicrosoft Windows Any
    2017-12-29 rik5 StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code