Re: Breakpoint bug [was Re: Breakpoint woes]

[John Swensen]

On Apr 13, 2009, at 11:33 PM, John W. Eaton wrote:

> On 13-Apr-2009, John Swensen wrote:
>
> | So, I think the problem I was describing above is actually a bug.   
> The
> | problem occurs because the bp_table class stores pointers to
> | octave_user_code objects that can become invalid without these items
> | being removed from the STL map in the bp_table class.  I have come  
> up
> | with a solution, but want input from others to know if they think it
> | is an acceptable solution.  The included patch has my proposed  
> solution.
> |
> | My next question is whether there is a way to force the symbol table
> | to update. I have the problem that after calling octave_env::chdir  
> the
> | symbol table doesn't update until the next time I press enter and go
> | to the next readline prompt.
>
> Do you mean the symbol table or the load path?

I guess I'm not sure what I mean.  I just know that after calling  
octave_env::chdir to move out of a directory containing a function  
with a breakpoint, if I look through my STL map containing  
octave_user_code pointers, the pointers are still valid and indicate  
the breakpoint still exists until after I ht return at the Octave  
prompt.  That is, somehow the changing of directory programmatically  
doesn't get processed until the next time the Octave prompt is  
advanced.  I am wondering if there is a way to do this programatically  
as I process things in the readline idle event loop.


> | diff -r 4bb94a71913b src/debug.cc
> | --- a/src/debug.cc    Sun Apr 12 20:40:53 2009 -0400
> | +++ b/src/debug.cc    Mon Apr 13 16:57:09 2009 -0400
> | @@ -376,10 +376,16 @@
> |           bp_map.erase (it);
> |       }
> |      }
> | -  else if (! silent)
> | -    error ("remove_all_breakpoint_in_file: "
> | -        "unable to find the function requested\n");
> | -
> | +  else
> | +    {
> | +      if (! silent)
> | +     error ("remove_all_breakpoint_in_file: "
> | +            "unable to find the function requested\n");
> | +
> | +      breakpoint_map_iterator it = bp_map.find (fname);
> | +      if (it != bp_map.end ())
> | +     bp_map.erase (it);
> | +    }
> |    tree_evaluator::debug_mode = bp_table::have_breakpoints ();
> |
> |    return retval;
> | diff -r 4bb94a71913b src/symtab.h
> | --- a/src/symtab.h    Sun Apr 12 20:40:53 2009 -0400
> | +++ b/src/symtab.h    Mon Apr 13 16:57:09 2009 -0400
> | @@ -1353,11 +1353,15 @@
> |    static void clear_functions (void)
> |    {
> |      for (fcn_table_iterator p = fcn_table.begin (); p !=  
> fcn_table.end (); p++)
> | -      p->second.clear ();
> | +      {
> | +     bp_table::remove_all_breakpoints_in_file (p->first, true);
> | +     p->second.clear ();
> | +      }
> |    }
> |
> |    static void clear_function (const std::string& name)
> |    {
> | +    bp_table::remove_all_breakpoints_in_file (name, true);
> |      clear_user_function (name);
> |    }
>
> I haven't looked at this in detail, but I think it might be better to
> call the remove_all_breakpoints_in_file function from the
> function/script object destructor.

Which file is this in, so I can go look at it?

> Should breakpoint information be stored directly in the list of tree
> objects that make up the body of a function/script instead of storing
> it in a separate table?

When I originally worked on the bp_table class, I had though about  
doing this, but decided against it since it seemed at the time that I  
would have to walk through every known function to get a complete list  
of breakpoints.  I am not 100% sure exactly the relationship between  
the symbol table and the tree walker.  I am willing to do a complete  
re-write of the guts of bp_table to always look at the underlying  
representation that Octave stores of functions and breakpoints, but  
would like to know if there is a more efficient way of doing it.  I  
agree it doesn't make a lot of sense to store breakpoint information  
in two places.

>

John Swensen