General comment: I've been seeing a *LOT* of pool creation/manipulation in
the various SVN code. My initial feeling is that we're going a bit overboard
with the pools, and that it will steer us into Bad Areas(tm). i.e. the
problem we've seen where a pool is destroyed while references within it
still exist.
IMO, I would ask people to be much more conservative with pool usage. Don't
just go and create/destroy them willy nilly. More pools, more confusion
("gee, which pool is this in?"). Create/dest of pools is only important
within high-level loops that are unbounded in size (the subpool is used to
impose a bound).
Cheers,
-g
On Mon, Oct 09, 2000 at 12:34:57AM -0400, Greg Hudson wrote:
> > Am I right in saying the path corruption problem still persists even
> > after Greg H's recent fix: 'make check' in libsvn_wc shows
> > corruption for me?
>
> I don't know; I haven't managed to reproduce any corruption at all,
> with or without my fix. (What platform are people seeing corruption
> on? Sometimes these bugs only manifest on particular architectures.
> I have access to machines running a variety of operating systems, but
> I only make a habit of building Subversion under Linux.)
>
> > It seems that sometimes the data of a string is getting reallocated
> > in a different pool than it was originally allocated it.
>
> This is okay if and only if the new and old pools both live as long as
> the string has to. If you find a place where a temporary subpool is
> allocated and passed to svn_string_append*() and destroyed before the
> string's lifetime is over, then there is a bug.
>
> Your debugging code looks useful for flagging cases that need
> examining.
>
> > The patch below stores the original pool in the string structure,
> > and detects when a realloc is attempted with a different pool and
> > prints a warning.
>
> At some point I was going to propose what you suggested, i.e. keeping
> track of the original pool in a string structure and nuking the pool
> arguments to svn_string_append*(), since you always want to use the
> same pool anyway. We should make sure to put a big fat comment in the
> string definition saying that the string doesn't own the pool, though.
> (This is because other structures which contain pools generally own
> the pool so that they can be destroyed independently of anything else.
> But we probably don't want that much overhead every string.)
>
> And we should also probably wait for Milestone 1 to be out to make
> such a fundamental change, of course.
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:10 2006