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

 
 

bug #44596: Post debug phenomena

Submitter:  Avinoam Kalma <avinoam>
Submitted:  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
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group administrator
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>
Group 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>
Group 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>
Group Member
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>
Group 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>
Group Member
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>
Group 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>
Group 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>
Group 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>
Group 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>
Group administrator
Fri 20 Mar 2015 11:50:06 PM UTC, comment #1: 

Confirmed.

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

a=isprime(2);

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>
Group Member

 

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

Attach Files:
   
   
Comment:
   

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)

    •  

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

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-f13d.
    Corresponding source code