[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problem in copy_versioned_files()?

From: John Szakmeister <john_at_szakmeister.net>
Date: 2003-12-03 01:57:43 CET

On Tuesday 02 December 2003 17:45, Julian Foad wrote:
> [snip]
> Is my patch that I have just sent in thread "Sub-pools for recursion" OK
> for this purpose? It also fixes the handling of errors which, in the
> original code above, is wrong in the case where svn_wc_adm_close returns an
> error.

Yeah, I saw that... it was bugging me that the there was a potential for a
memory leak. :-) I looked at your other patch, and it seemed to address the
problems just fine. +1 by me.

> I considered putting an "svn_wc_adm_close" in the error return path ("if
> (err->apr_err != SVN_ERR_WC_NOT_DIRECTORY)"), but I don't think that's
> necessary.

That is why I haven't done much with that yet. I was trying to think ahead a
little and was thinking about the fact that maybe semantics would change a
little. Like reads of the entries might actually take out a lock. In that
case, it wouldn't be removed, causing the user to have to do an 'svn cleanup'
if we didn't have svn_wc_adm_close() in the error path. I'm probably just
being paranoid though. :-)

> I am also playing with the following patch:
> Index: subversion/libsvn_wc/lock.c
> ===================================================================
> --- subversion/libsvn_wc/lock.c (revision 7899)
> +++ subversion/libsvn_wc/lock.c (working copy)
> @@ -738,6 +738,9 @@
> assert (! adm_access->set_owner || apr_hash_count (adm_access->set)
> == 0); }
> + /* Invalidate the baton so that attempts to use it will be caught. */
> + memset (adm_access, 0, sizeof(*adm_access));
> +
> return SVN_NO_ERROR;
> }
> It catches the error that is the subject of this message, but makes lots of
> other tests fail too. I'm still investigating whether it is finding real
> bugs or is a wrong thing to do.

Interesting that this caused other errors. I'm curious to know what you
find! :-)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 3 01:53:28 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.