This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [RFA] deleting breakpoints inside of 'commands' [Repost]


Andrew Cagney wrote:
> 
> >
> > I've looked your patch over, and it looks correct to me.  Having said
> > that, I think that the correctness of this patch is much less obvious
> > than the version that made a copy of the command chain associated with
> > a breakpoint.  I don't fault you for this; the changes in your current
> > patch are somewhat more distributed which means that there's more code
> > to consider (and more ways for something to get fouled up later on).
> 
> And guess what (sorry but this is funny :-) I suspect it does contain a
> bug.  Try:
> 
>         break main
>         commands
>         delete NN
>         leak-memory
>         end
> 
> The command ``leak-memory'' is invalid and will lead to an error() call
> and that will in turn long jump over the code that would free the list.
> 
> While the duplicate version contains the same bug, I suspect it is
> easier to fix vis:
> 
>         o       duplicate list
>         o       add list to a cleanup
>         o       run command
>         o       do cleanups
> 
> I suspect to do this with the non-duplicate version you'll need to add a
> catch_exceptions() call (nee catch_errors()) and check the state of that
> ->execute variable to figure out what to do.
> 

I don't see why it is not possible to register a cleanup in Don's latest
solution.  The function would do nothing unless a "delete NN" was executed
before we bail out.



> I do tend to agree with Kevin though.  Some times simplicity is best.
> 

I wish you have thought like that in previous instances. ;-)

And I don't think Don's latest patch is complex, or considerably more
complex than the simplistic copy approach (or hack!).  It is elegant 
(although Kevin's comments are valid and should be incorporated).



If Don can add a cleanup function and do the polishing suggested by Kevin
on his last patch I suggest that we stick with that one.


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]