> 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.
Received on Sat Oct 21 14:36:10 2006