This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [OB] Add cleanup, source.c
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Jim Blandy <jimb at codesourcery dot com>
- Cc: Eli Zaretskii <eliz at gnu dot org>, Michael Snyder <msnyder at sonic dot net>, drow at false dot org, Michael dot Snyder at access-company dot com, gdb-patches at sourceware dot org
- Date: Wed, 4 Jul 2007 10:37:57 -0700
- Subject: Re: [OB] Add cleanup, source.c
- References: <20070628224815.GC12578@caradoc.them.org> <655C3D4066B7954481633935A40BB36F041427@ussunex02.svl.access-company.com> <20070628231153.GA14231@caradoc.them.org> <11470.12.7.175.2.1183080998.squirrel@webmail.sonic.net> <20070629113407.GA13561@caradoc.them.org> <003201c7ba8c$d6e0e840$677ba8c0@sonic.net> <uejjtmz8z.fsf@gnu.org> <000b01c7bb2f$d88684e0$677ba8c0@sonic.net> <uabuhmhfa.fsf@gnu.org> <m3sl854b0j.fsf@codesourcery.com>
> What's going on here is that GDB uses one construct, cleanups, to
> implement two different useful behaviors, and does so in a perilous
> way.
> where 'cleanup_success' discards failure handlers and runs finally
> handlers. The 'error' function would call a companion to that named
> 'cleanup_on_failure', which runs both finally and failure handlers.
A very interesting analysis, Jim. I confess that up to today, I have
been using the two concepts interchangeably, so I'm pretty sure that
I have introduced the potential for memory leaks :-(.
> So. Only 270 calls to 'do_cleanups' and 47 calls to
> 'discard_cleanups' to examine.
Good luck. Let me know if you'd like some help, I feel partly responsible
for the mess. We can split the number of files that need to be inspected.
--
Joel