[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:
<http://savannah.gnu.org/bugs/?30490>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [Octave-bug-tracker] [bug #30490] Error in breakpoint tree walker, John Swensen, 2010/07/19
- [Octave-bug-tracker] [bug #30490] Error in breakpoint tree walker,
John Swensen <=
- [Octave-bug-tracker] [bug #30490] Error in breakpoint tree walker, John W. Eaton, 2010/07/29
- [Octave-bug-tracker] [bug #30490] Error in breakpoint tree walker, anonymous, 2010/07/29
- [Octave-bug-tracker] [bug #30490] Error in breakpoint tree walker, John W. Eaton, 2010/07/30
- [Octave-bug-tracker] [bug #30490] Error in breakpoint tree walker, anonymous, 2010/07/30
- [Octave-bug-tracker] [bug #30490] Error in breakpoint tree walker, John W. Eaton, 2010/07/30
- [Octave-bug-tracker] [bug #30490] Error in breakpoint tree walker, John W. Eaton, 2010/07/30
- [Octave-bug-tracker] [bug #30490] Error in breakpoint tree walker, John Swensen, 2010/07/30
- [Octave-bug-tracker] [bug #30490] Error in breakpoint tree walker, John W. Eaton, 2010/07/30