bugGNU Octave - Bugs: bug #41338, dbstatus() doesn't return all...

 
 

bug #41338: dbstatus() doesn't return all breakpoints when called in a function

Submitter:  Markus Appel <mappel>
Submitted:  Fri 24 Jan 2014 06:03:32 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 3.8.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 11 Feb 2014 10:29:03 PM UTC, comment #6: 

Sorry, I read quickly and didn't see it was already fixed...

I didn't mean to hijack this bug report.

Here's the new bug report as you suggested:
https://savannah.gnu.org/bugs/index.php?41556

(I can't figure out how to display the markdown help, so I couldn't get the code monospace font in dedicated box.)

Jérôme <jeromegnu>
Tue 11 Feb 2014 10:13:19 PM UTC, comment #5: 

I fixed the original bug in the changeset mentioned.  But it won't be released publically until version 4.2.  The use case you mention (saving and restoring breakpoints) is a useful one and I would like to have that too.  As you may have found, however, struct inputs to dbstop are not supported yet.  When I run your test script I get


dbstop (s)
error: dbstop: struct input not implemented


at the very last line.

Rather than try and re-direct this closed bug report I think you should open a new bug report about not being able to set multiple breakpoints with dbstop.

Rik <rik5>
Group administrator
Tue 11 Feb 2014 09:55:51 PM UTC, comment #4: 

Hi.

I stumbled across this today.

This might be anecdotal, but as a sidenote, here is my use case.

My objective is to save breakpoints while clearing variables :

-------------------

s=dbstatus;
save('breakpoints.mat', 's');
clear all
close all
clc
load('breakpoints.mat', 's');
dbstop(s);

-------------------

This works on Matlab. There may even be a nicer solution (?), but anyway, it does the trick.

However, on octave, when in my main script, all breakpoints outside of this main script are not returned by dbstatus, and therefore, these are cleared.

E.g.

-------------------

octave:1> dbstop('file1',1)
ans =  1
octave:2> dbstop('file2',1)
ans =  1
octave:3> dbstatus
breakpoint in file1 at line 1.
breakpoint in file2 at line 1.
octave:4> file2
stopped in /home/jerome/projets/octave/file2.m at line 1
1: b=15;
debug> dbstatus
breakpoint in file2 at line 1.
debug> dbstatus('file1')
breakpoint in file1 at line 1.

-------------------

Thanks for looking into this.

Jérôme <jeromegnu>
Sun 26 Jan 2014 02:22:07 PM UTC, comment #3: 

Thanks Rik.
I suspected octave wanting to be helpful, but I wanted to check at runtime in my function if I was trying to debug something and avoid calling parcellfun as this ends in a mess when the subprocesses drop into debug mode (probably some room for improvement here as well).
I guess I will be switching back to dev then soon.

Markus Appel <mappel>
Fri 24 Jan 2014 08:49:32 PM UTC, comment #2: 

I checked in a changeset that fixes it here (http://hg.savannah.gnu.org/hgweb/octave/rev/bb162f81881d).  This is on the development branch so you will need to build from Mercurial sources or wait a very long time until version 4.2 is released.

Rik <rik5>
Group administrator
Fri 24 Jan 2014 06:59:27 PM UTC, comment #1: 

The issue is that Octave is trying to be "helpful" about what breakpoints it shows.  When you are debugging a function, and in a function context, dbstatus gives you the list of breakpoints in the current function.  In the same way, calling dbclear while inside a debugging context will clear the breakpoints for the current file.

Lots of room for improvement here.  It seems like an easy one would be only have the special behavior for dbstatus when actually in debugging mode.  The attached patch seems to work for me.

I think these internal changes probably need to go on to the development branch rather than the 3.8.X branch since they would change behavior that some coders may have come to rely on.

(file #30364)

Rik <rik5>
Group administrator
Fri 24 Jan 2014 06:03:32 PM UTC, original submission:  

dbstatus() called within a function to retrieve the list of all active breakpoints doesn't show all of them. Only when specifically asked, dbstatus("func") returns the breakpoints in func.

Code example:

dbclear magic
allbreaks = dbstatus()
magicbreaks = dbstatus("magic")
% both above return empty struct

dbstop magic

allbreaks = dbstatus()
magicbreaks = dbstatus("magic")
% both above show breakpoint in magic

function lookforbreaks ()
   allbreaks = dbstatus()
   magicbreaks = dbstatus("magic")
endfunction

lookforbreaks()
% only dbstatus("magic") sees breakpoint in magic


When an additional breakpoint is set in the function lookforbreaks(), dbstatus() within the function sees only that one.

Markus Appel <mappel>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #30364:  patch.dbstatus added by rik5 (680B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jeromegnu (Posted a comment)
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by mappel (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
    2014-01-24 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2014-01-24 rik5 Attached File- Added patch.dbstatus, #30364
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code