Re: Breakpoint woes

[John Swensen]

On Apr 20, 2009, at 4:18 PM, John W. Eaton wrote:

> On 20-Apr-2009, John Swensen wrote:
>
> | So I think I have an in-between solution that may fix all these
> | problems. I agree that we should be storing the entire filename in  
> the
> | bp_table class. However, I find no reason why we should be storing  
> the
> | octave_user_function pointer in a map with the function name as the
> | key.  Instead, I will only store the list of functions that have a
> | breakpoint. Then, when bp_table::do_get_breakpoint_list is called I
> | will check each function for breakpoints using get_user_code(),
> | getting the function body, and listing the breakpoints. If the  
> number
> | of breakpoints comes back empty, then I will remove the full  
> function
> | path and name from the list of functions.
> |
> | Does this sound like a reasonable solution? I like this because the
> | bp_table becomes a much more passive class.
>
> Yes, I think so.
>
> Thanks,
>
> jwe

So this was quite an easy fix, and I think it is a much better  
solution, but I still have one problem.  I added a little printf to  
the octave_user_code destructor to see when it is actually being  
called.  I found that if I set a breakpoint in a function in the  
current directory, then 'cd' out of the directory, the destructor  
isn't called immediately.  Instead, it appears the object isn't  
destroyed until certain functions are called.  I have verified the  
following things cause this cleanup to occur, but there may be many  
more:
1) call dbstatus
2) call dbstop with the same function name as was used to set the  
breakpoint
3) trying to call the function with the same name as was used to set  
the breakpoint

Plus, it seems that it is somehow tied to the octave readline prompt  
also.  I tried writing a simple OCT file that launched a new thread  
and continuously called bp_table::get_breakpoint_list, just as  
dbstatus does. However, this didn't cause the octave_user_code  
destructor to be called unless I also had the thread set rl_done=1.

Any suggestion on where to look next? I suppose this is "good enough"  
and I can issue the rl_done from my IDE to force directory changes to  
affect breakpoints immediately, but it would be nice if I could figure  
out what is being called after each iteration of the readline loop  
that causes these things to be updated.

John Swensen