[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #30490] Error in breakpoint tree walker

From: John Swensen
Subject: [Octave-bug-tracker] [bug #30490] Error in breakpoint tree walker
Date: Fri, 23 Jul 2010 14:26:16 +0000
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-us) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16

Follow-up Comment #1, bug #30490 (project octave):

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.



Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]