bugGNU Octave - Bugs: bug #44596, Post debug phenomena


bug #44596: Post debug phenomena

Submitted by:  Avinoam Kalma <avinoam>
Submitted on:  Fri 20 Mar 2015 09:57:54 PM UTC  
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Confirmed Assigned to:  None
Originator Name:  Avinoam Open/Closed:  Open
Release:  6.1.0 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)

Tue 01 Dec 2020 04:43:02 PM UTC, comment #15: 

Still the same with Octave 6.1.0 (on Windows at least) if "Print debug location in Command Window…" is not selected.

Markus Mützel <mmuetzel>
Project Member
Tue 12 Mar 2019 05:16:06 AM UTC, comment #14: 

I got the same behaviour as Mike described in comment #12 in Windows with Octave 5.1.0

Avinoam Kalma <avinoam>
Project Member
Mon 11 Mar 2019 07:11:43 PM UTC, comment #13: 

Yes, the first time a breakpoint is hit, the message is still shown. And I needed to toggle the setting several times in order to reproduce the bug again. But this is definitely a good point to look at.

Torsten Lilge <ttl>
Project Member
Mon 11 Mar 2019 06:10:22 PM UTC, comment #12: 

Oh, I didn't know that setting existed. It looks like it is causing this bug to me.

If I start Octave with "Print debug location in Command Window…" enabled, everything works fine.

If I start Octave with that setting disabled, then I can reproduce this bug. It also does show the debug location on the first breakpoint hit, but not the second, and after the second is when the prompt stops displaying a new line. Whatever it is that that setting does seems to be interfering with normal terminal output, and misses suppressing the first "stopped in …" message.

Mike Miller <mtmiller>
Project Administrator
Sun 10 Mar 2019 05:49:57 PM UTC, comment #11: 

Regarding the output about the current line, have you checked the preference in the "Command" tab (Print debug location ...)?

But now I can confirm that pressing "Enter" does not produce a new line anymore.

Torsten Lilge <ttl>
Project Member
Sun 10 Mar 2019 05:03:48 PM UTC, comment #10: 

I can still reproduce this on GNU/Linux with Octave 5.1 and on the development branch following the steps in comment #5. The prompt is shown correctly as ">> " but pressing Enter does not print a new line. Also,

stopped in …/isprime.m at line 66
66:   if (nargin != 1)

is not shown on the second and subsequent calls to isprime.

Mike Miller <mtmiller>
Project Administrator
Sun 10 Mar 2019 09:50:57 AM UTC, comment #9: 

This is not reproducible for me on the dev branch under Linux (debian/gnome). I will test on windows as soon as I have solved some problems with my mxe environment.

Torsten Lilge <ttl>
Project Member
Fri 08 Mar 2019 08:01:14 PM UTC, comment #8: 

I have re-tested this under Linux with Octave 5.1.0 (self compiled from official tar-ball). And my observations from comment #6 are all still the very same. So this odd behavior IS still alive.

Hartmut <hardy>
Sun 03 Mar 2019 03:58:29 PM UTC, comment #7: 

Version 4.2.0 is deprecated and no longer supported.  Please try with the latest stable release which is 5.1.0.  The problem is likely to have been fixed.

Rik <rik5>
Project Administrator
Wed 28 Dec 2016 08:43:32 PM UTC, comment #6: 

I also see this on LINUX (Octave 4.2.0, self compiled from official release tar-ball, under Ubuntu 16.04):

  • I do the very same steps as described in the first code box of comment #5. The command promt looks alright afterwards (">> "). But when I then press the "Enter" key in the Command Windows Tab, nothing happens. No new command line appears. Even after typing "2+2", pressing Enter, and receiving the answer "ans = 4" nothing will happen after pressing the Enter key again on the new empty command line.
  • After execution of the second code box of comment #5, the behavior is the very same (still Linux) as described above for the first code box.
Hartmut <hardy>
Wed 28 Dec 2016 06:13:55 PM UTC, comment #5: 

I can only get this to happen on Windows, not Linux.  I used

octave-4.2.0 -f
dbstop isprime 66
a = isprime (2);
## Switch to Editor Tab, Hit Continue Button
## Switch back to Command Window Tab
a = isprime (2);
## Switch to Editor Tab, Hit Continue Button
## Switch back to Command Window Tab

More interesting behavior, again only on Windows, with this code:

octave-4.2.0 -f
dbstop isprime 66
dbstop isprime 77
a = isprime (2)
## Switch to Editor Tab, Hit Continue Button
## Hit Continue Button a second time
## Switch back to Command Window Tab
a = 1>

There was an extra ">\n" in the output buffer.

This is likely to be caused by the use of the _db_next_breakpoint_quiet_ function within the GUI which sets

  octave::tree_evaluator::quiet_breakpoint_flag = state;

A complete stab in the dark, but maybe somewhere we need a std::endl instead of just "\n" so that the output is truly flushed somewhere in the print routines.

Rik <rik5>
Project Administrator
Sat 24 Dec 2016 07:45:37 AM UTC, comment #4: 

Changing OS to any and and release to 4.2.0

Avinoam Kalma <avinoam>
Project Member
Fri 23 Dec 2016 10:04:02 PM UTC, comment #3: 

This issue is (at least partly) still present in Octave 4.2.0.

After the debugging procedure described in comment #0, I still do not get a new line when pressing the return key on a blank line.

This happens also in Linux, not just under Windows as it is currently suggested be the tags.

Hartmut <hardy>
Tue 02 Jun 2015 04:32:47 PM UTC, comment #2: 

Retagging release from 4.0.0-rc1 to 4.0.0.

John W. Eaton <jwe>
Project Administrator
Fri 20 Mar 2015 11:50:06 PM UTC, comment #1: 


I wonder if it is related to the fact that pressing return on a blank line does not, in fact, advance to the next line as it does in Linux.  It may be that the 'continue' button issues a newline to the command window which, instead of going to the next line, merely redraws the prompt and remains in place at the same vertical location.

Rik <rik5>
Project Administrator
Fri 20 Mar 2015 09:57:54 PM UTC, original submission:  

I set a breakpoint in a routine, for example in isprime.m, line 66,
and write


the program hits the breakpoint, and Octave enters debug mode.
I press continue, the program continues and exits debug mode.
If I do it again (a=isprime(2) and then continue) I get

>> ug>

which is caused from the leftovers of debug, and the regular prompt
(see attached file). Moreover, if I press ENTER Octave does not
move the cursor to the next line, unless another character is typed.

Avinoam Kalma <avinoam>
Project Member


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

Attach Files:

Attached Files
file #33415:  debug.png added by avinoam (102KiB - image/png)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by avinoam (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-12-01 mmuetzel Release5.1.0 => 6.1.0
    2019-03-09 mtmiller Release4.2.0 => 5.1.0
    2016-12-24 avinoam Release4.0.0 => 4.2.0
        Operating SystemMicrosoft Windows => Any
    2015-06-02 jwe Release4.0.0-rc1 => 4.0.0
    2015-03-23 rik5 StatusNone => Confirmed
    2015-03-20 avinoam Attached File- => Added debug.png, #33415

    Back to the top

    Powered by Savane 3.6