A while back I submitted a patch to Octave for the bp_table class.
This class provided a class with static message to easily add,
remove, and retrieve breakpoints. However, as I have recently been
working with including breakpoint capabilities into the OctaveDE
editor, I realize the bp_table interface to Octave breakpoint is
seriously flawed. I will give a few examples, then describe what I
think the problem is and ask for suggestions on how to fix it. I
can work on patches, but am not sure exactly where all the problems
are.
Example 1:
1) Set a breakpoint
2) Call 'clear all'
3) Call 'dbstatus'
Example 2:
1) Set a breakpoint in a file in the current directory
2) Change directories (e.g. 'cd ..')
3) Call 'dbstatus'
There may be many more things that cause this problem. In
particular, I think the problem occurs when breakpoints are changed
in the actual symbol table, but aren't updated in the bp_table
representation of breakpoints. One solution for this is to have the
bp_table class run through the entire symbol table looking for
breakpoints when dbstatus is called, rather than storing pointers to
and out-of-date symbol table. Another option would be to have
events like saving a file, clearing all, changing directories, etc
call back to the bp_table with updates. Or, is it as simple as
looking at the results of the out_of_date_check in
do_get_breakpoint_list and removing items from the bp_map based on
these results. Maybe someone else has a suggestion on what the
problem really is and the best way to solve it.
John Swensen
GDB Output for Example 2
Octave:1> dbstop('pickle')
ans = 2
octave:2> cd ..
octave:3> dbstatus
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x012df5cf in bp_table::do_get_breakpoint_list (this=0x34e4a60,
address@hidden) at debug.cc:446
#2 0x012ea249 in bp_table::get_breakpoint_list
(address@hidden) at debug.h:108
#3 0x012e349f in std::map<std::string, std::map<int, int,
std::less<int>, std::allocator<std::pair<int const, int> > >,
std::less<std::string>, std::allocator<std::pair<std::string const,
std::map<int, int, std::less<int>, std::allocator<std::pair<int
const, int> > > > > >::operator= () at stl_map.h:599
#4 0x012e349f in Fdbstatus (address@hidden, nargout=0) at
debug.cc:585
#5 0x0170d742 in octave_builtin::do_multi_index_op (this=0x3852800,
nargout=0, address@hidden) at ov-builtin.cc:107
#6 0x016baf59 in octave_value::do_multi_index_op (this=0x38a1a00,
nargout=59382272, address@hidden) at ov.cc:1115
#7 0x01896773 in tree_identifier::rvalue (this=0x34df270,
nargout=0) at pt-id.cc:86
#8 0x01895ece in tree_identifier::rvalue1 (this=0x34df270,
nargout=59382272) at pt-id.cc:107
#9 0x0188e1ca in tree_evaluator::visit_statement (this=0x1ffac20,
address@hidden) at pt-eval.cc:695
#10 0x0188ce0f in tree_evaluator::visit_statement_list
(this=0x1ffac20, address@hidden) at pt-eval.cc:731
#11 0x015cf32a in main_loop () at toplev.cc:559
#12 0x0154dbbf in octave_main (argc=6, argv=0xbfffcda0, embedded=0)
at octave.cc:882
#13 0x00001ff0 in main (argc=59382272, argv=0x38a1a00) at main.c:35
#14 0x00001f96 in start ()
(gdb)
breakpoint_bug.patch