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

[Fernando Nasser <fnasser@cygnus.com>]

Andrew Cagney wrote:
> 
> >
> > I have the same concerns.
> > We haven't heard from Don yet.  Maybe he has some compromise solution.
> >
> > Anyway, I find the copy solution a hack.
> >
> > One way to fix this is to have the chain of commands as an object with
> > use count.  It is only freed when the count is down to zero again.
> >
> > When you associate it with a breakpoint it goes up to 1.  When you
> > get it to execute it goes up to 2.
> >
> > When a breakpoint is deleted, it deallocates it.  If the count goes
> > to zero memory is freed.  But if the script is being executed (and
> > is deleting self) the count will go to 1 and nothing else happens
> > until the script finishes executing and the chain is freed (then
> > the count goes to zero and memory is deallocated).
> 
> Rememeber, the patch doesn't have to be perfect, just acceptable.  In
> this case, the change eliminates a stray pointer problem (which would
> likely still occure with reference counters) and hence makes gdb far
> more robust - I put robustness and maintainability at a much higher
> priority level then performance.
> When someone manages to demonstrate that the copy is a significant
> overhead (using ``set maint profile on/off'' [:-)]) then I think we
> should refine the code to do what you propose (or gasp add a garbage
> collector :-/).  However, Don, if you're upto the task.
> 

Yes, I am one that keeps saying that we should fix gross bugs as soon
as possible, even if we have to come back and improve on the fix.

However, it may be possible to fix it correctly with a little more
effort if Don is willing.  Otherwise we add it with a _huge_ FIXME
and add the cleanup task to the TODO list.

Don?

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