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

Submitted by:  Marshall <marsian>
Submitted on:  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

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)

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>
Project 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

debug_mode: 1
ans =  0.017452

Rik <rik5>
Project 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 ();

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>
Project 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

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

Rik <rik5>
Project 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:


This seems to fix the problem for me.

John W. Eaton <jwe>
Project 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>
Project Administrator
Fri 29 Dec 2017 01:37:31 AM UTC, comment #4: 

%debug_on_interrupt (1)
more off
function f()

dbstop f

% 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>
Project 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>
Project 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:

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)

    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 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.5