This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: Patch: catch_errors() cleanup chain restore
- To: nsd at cygnus dot com
- Subject: Re: Patch: catch_errors() cleanup chain restore
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 17 Feb 2000 15:31:47 +1100
- CC: gdb-patches at sourceware dot cygnus dot com, ezannoni at cygnus dot com
- Organization: Cygnus Solutions
- References: <200002170342.DAA03488@nog.bosbc.com>
nsd@cygnus.com wrote:
>
> >I can
> >(just) live with GDB occasionally leaking memory
>
> The memory leak happened to be in one of the first RETURN_MASK_ERROR
> cases I checked, so I stopped checking. There might be worse bugs
> lurking in other cases.
>
> >This makes me think that the catch_errors() and return_to_top_level()'s
> >current unhealthy obsession with those error_return and quit_return
> >buffers should be cured.
>
> Yes, please!
[...]
> >BTW, as far as I can tell the FIXME comment I made is still true -
> >fixing the problem involves examining every catch_errors call :-(
Actually, the fixme comment contains a bug!
val = (*func) (args);
/* FIXME: cagney/1999-11-05: A correct FUNC implementaton will
clean things up (restoring the cleanup chain) to the state
they were just prior to the call. Technically, this means
that the below restore_cleanups call is redundant.
Unfortunatly, many FUNC's are not that well behaved.
restore_cleanups should either be replaced with a do_cleanups
call (to cover the problem) or an assertion check to detect
bad FUNCs code. */
The restore_cleanups() call is always needed. However, before that call
there should either be a call to do_cleanups() or a check that the
cleanup chain has been emptied. Without that GDB could end up leaking
memory. Problem is that I suspect that there is code abusing the
current behavour :-(
Andrew