Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Elena Zannoni <ezannoni@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: carlton@kealia.com, gdb-patches@sources.redhat.com
Subject: Re: Avoid obstack_free in cp-namespace.c
Date: Mon, 09 Feb 2004 22:42:00 -0000	[thread overview]
Message-ID: <16424.3095.770087.850919@localhost.redhat.com> (raw)
In-Reply-To: <20040209211010.GA25073@nevyn.them.org>

Daniel Jacobowitz writes:
 > 
 > [For the curious I've audited the remaining uses of obstack_free in GDB. 
 > The ones in jv-lang.c and stabsread.c are suspicious but seem to be OK, and
 > the rest are fine except for this one - they release whole obstacks.]

I already did this in my cleanups. For the curious, you might as well
explain the whole story. The obstack_free function takes a pointer to
where in the stack it must start the deletion from (much like the
cleanup chains have a pointer to where to start the cleanups). The
obstack_free's in jv-lang.c and stabsread.c are done after some local
stuff is allocated to the obstack. Only the local stuff is deleted
from the obstack. Of course this assumes that nothing between the
obstack_alloc and the obstack_free allocates anything else on the same
obstack. For this reason other files use temporary obstacks. Maybe
jv-lang.c and stabsread.c could do the same. This one had the same
assumption.

Releasing the whole obstack is not safe per se. It is safe only under
the condition that we know the obstacks memory is no longer
needed. In GDB we blow away the obstacks only when we get rid of the
whole objfile(s). 

elena


  parent reply	other threads:[~2004-02-09 22:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-09 21:10 Daniel Jacobowitz
2004-02-09 21:20 ` David Carlton
2004-02-09 22:25   ` Daniel Jacobowitz
2004-02-09 22:42 ` Elena Zannoni [this message]
2004-02-10  5:44   ` Eli Zaretskii
2004-02-10 17:28     ` Elena Zannoni
2004-02-10 18:55       ` Eli Zaretskii
2004-02-10  5:44 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16424.3095.770087.850919@localhost.redhat.com \
    --to=ezannoni@redhat.com \
    --cc=carlton@kealia.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox