bugGNU Octave - Bugs: bug #30490, Error in breakpoint tree walker

 
 

bug #30490: Error in breakpoint tree walker

Submitted by:  John Swensen <jpswensen>
Submitted on:  Mon 19 Jul 2010 06:28:13 PM UTC  
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  John W. Eaton <jwe>
Originator Name:  jpswensen Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

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)

Fri 30 Jul 2010 11:12:34 PM UTC, comment #7:

This seems to have fixed it.  I tried a bunch of other places to put breakpoints and they all seem to work now.  Thanks for fixing this so quickly, and sorry I couldn't be more help in solving this.  I tried to chase it down but just didn't know what was going on in all the pt* files

John Swensen <jpswensen>
Fri 30 Jul 2010 09:22:02 PM UTC, comment #6:

I checked in the following additional changeset:

  http://hg.savannah.gnu.org/hgweb/octave/rev/960065af9f0f

Does it help?

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
Fri 30 Jul 2010 03:04:23 PM UTC, comment #5:

I checked in a changeset that should fix the problem of not stopping on if (and switch) statements:

  http://hg.savannah.gnu.org/hgweb/octave/rev/6abf966379de

The problem of dbstatus not listing a breakpoint that is set inside an if block (or other statement types) looks like a separate problem to me.  I'm thinking about the right way to fix that as well, but I don't have a solution yet.

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
Fri 30 Jul 2010 02:06:17 PM UTC, comment #4:

I think I have a partial fix.  I added a call to tree::set_breakpoint() (i.e. a call to the base class's virtual function to actual set the bp boolean flag to true).  This now is "almost"working.  What I mean by "almost" is as follows:

1) Setting a breakpoint on an if line works and shows up in calls to dbstatus
2) Setting a breakpoint on a line inside and if..else..end block works, but does not show up in calls to dbstatus.

And to clarify, when I say the breakpoint works, I mean that when the function is executed the function stops on the line where the breakpoint was set.  So for breakpoints set on a line inside an if..else..end block (and I'm assuming the same for a while block but haven't tested it) the breakpoint is hit when executing the function, but does not show up in the call to dbstatus.

Anonymous
Fri 30 Jul 2010 03:04:23 AM UTC, comment #3:

This patch now makes it so the breakpoints appear in the results of dbstatus, but they are no longer hit when executing the function.  You can test this easily with the 'testifs.m' and 'testnoifs.m' that I included with the original bug report.

Anonymous
Thu 29 Jul 2010 09:51:38 PM UTC, comment #2:

I checked in the following change which appears to fix the problem for me.

http://hg.savannah.gnu.org/hgweb/octave/rev/e5c752231985

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
Fri 23 Jul 2010 02:26:15 PM UTC, comment #1:

I have a few more bits of information about this bug.  I have followed the path of execution for both setting breakpoints and getting a list of breakpoints and am now even more confused.  For setting a breakpoint, in debug.cc the function do_add_breakpoint is called by dbstop().  This in turn finds the appropriate line of code and calls set_breakpoint (lineno) on the tree_statement_list, which creates and instance of a tree_breakpoint object (which is derived from tree_walker) with the line number and the enum associated with setting a breakpoint and then accepts the object and begins walking the tree.  This causes octave to call the tree_walker method called visit_statement_list which in turn calls visit_statement for each element in the list.  Either directly or indirectly, visit_statement ends up calling take_action for each command or expression in the list.

In the take_action function with the following prototype in pt-bp.cc,
tree_breakpoint::take_action (tree_statement& stmt)
I confirmed that for setting a breakpoint with my two test cases (breakpoint on an if..else line and not an if..else line) that tree_statement::set_breakpoint is in fact called.  In the case of the line containing an if..else tree_statement::set_breakpoint indicates the breakpoint was set for a tree_command and without an if..else it was set for a tree_expression.  I also confirmed that the base class set_breakpoint function was called from pt.h.

Now here is the strange part for the case of placing a breakpoint on a line with and if..else statement.  After returning up the call stack to tree_breakpoint::take_action, I decided to query the tree_statement to verify that the breakpoint had been set and called tree_statement::is_breakpoint for the stmt instantiation for which I had just called stmt.set_breakpoint().  Inexplicably it returned false.  I am at a loss to describe why this is the case, but hope this extra information might help the people who know the interpreter and tree walkers better than I to help me fix this bug.

 
John Swensen <jpswensen>
Mon 19 Jul 2010 06:28:13 PM UTC, original submission:

I don't understand how the tree walkers work and how the parsed m files are stored internally in Octave, so maybe this is expected behavior.  I have attached two sample scripts.  One contains a simple assignment and the other contains assignments within an if..else..end statement. I have placed the results of setting breakpoints with dbstop() and querying for breakpoints with dbstatus().  Unfortunately, in the example with the if..else..end statements the breakpoints are set, but are not reported through dbstatus().  To try and chase down the problem, there are a lot of my own debug statements I inserted into debug.cc. 

### Example with a test with if statements
octave:1> zz = dbstop('testwithifs',0)
zz =  3
octave:2> dbstatus('testwithifs')
Match: testwithifs
SList (0): testwithifs
****Comparisons - (==):1   (.strcmp): 1
Processing function: testwithifs
Num breakpoints: 0
Number of breakpoints: 0
octave:3> testwithifs(100,10)
stopped in /home/jpswensen/src/octave/src/testwithifs.m at line 3
3: if a == 100.0
debug> dbcont
ans =  100
octave:4>

### Example with no if statements
octave:1> zz = dbstop('testnoifs',0)
zz =  3
octave:2> dbstatus('testnoifs')
Match: testnoifs
SList (0): testnoifs
****Comparisons - (==):1   (.strcmp): 1
Processing function: testnoifs
Num breakpoints: 1
Processing breakpoints: testnoifs
****Processing breakpoint: 3
Number of breakpoints: 1
Breakpoint in testnoifs at line(s) 3.
octave:3> testnoifs(100,10)
stopped in /home/jpswensen/src/octave/src/testnoifs.m at line 3
3: a = b*100;
debug> dbcont
ans =  10000
octave:4>

The problem appears to be in do_get_breakpoint_list() in the following two lines:
   octave_value_list bkpts = cmds->list_breakpoints ();
   octave_idx_type len = bkpts.length ();
When breakpoints are placed on a line containing an if/else statement, it doesn't appear in this list of breakpoints even though (as can be seen from the output above) it is clearly being stored as a breakpoint and hit when the line is reached.

John Swensen <jpswensen>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #21012:  testnoifs.m added by jpswensen (38B - text/x-objcsrc)
file #21013:  testwithifs.m added by jpswensen (75B - text/x-objcsrc)

 

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 jpswensen (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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-31 jwe StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2010-07-30 jwe StatusConfirmed => In Progress
        Assigned toNone => jwe
    2010-07-30 jwe StatusFixed => Confirmed
        Open/ClosedClosed => Open
    2010-07-29 jwe StatusNone => Fixed
        Open/ClosedOpen => Closed
    2010-07-19 jpswensen Attached File- => Added testnoifs.m, #21012
        Attached File- => Added testwithifs.m, #21013

    Back to the top


    Powered by Savane 3.4