[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Breakpoint woes
From: |
John Swensen |
Subject: |
Breakpoint woes |
Date: |
Wed, 8 Apr 2009 08:49:15 -0400 |
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 woes,
John Swensen <=
- Breakpoint woes, John W. Eaton, 2009/04/20