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

Re: apr_pool_clear() core-dumps for svn+ssh. Any help?

From: Philipp Marek <philipp_at_marek.priv.at>
Date: 2006-09-08 19:05:07 CEST

On Friday 08 September 2006 15:01 Philip Martin wrote:
> "Ph. Marek" <philipp@marek.priv.at> writes:
> > /* This is a bit complicated.
> > *
> > * With the file:/// protocol, the source and destination
> > * filehandles are not closed by the subversion libraries;
> > * with svn+ssh:/// they are.
> That doesn't sound right, have you identified the bit of Subversion
> code that does the close? What about the other RA layers? It would
> appear that this should be fixed in Subversion.
I have already found the cause and fixed the problem.

The long story:
I need the streams passed to apply_textdelta() to be closed at a certain code
point, to get the correct mtime and ctime *after* all modifications.
So I created a new subpool from the pool given to the apply_textdelta
callback, do the apr_file_open() from this subpool and call apr_pool_clear()
in file_close() to ensure that the files are no longer open.

That works fine for file:/// urls, but crashes with svn+ssh:// (didn't test
svn://, http:// or https://).

The cause seems to be that the pool given to apr_pool_clear() (the parent
pool, so to say) seems to be cleared in the file_close() callback *for
svn+ssh:// urls*, but not for file://.
So the pointer I got for the subpool is no longer valid, and so
apr_pool_clear() crashes for me.

To fix this I now created the subpool from the pool given at the
directory_open() or directory_add() callbacks, because these are certainly
still valid at the time the file_close() callback is run.

So, it's subversions bug in the way that the behaviour is different depending
on the url used (which should not be IMO), and in that the pools for *one
file* get cleared before the file_close() callback - which makes it hard to
pass data to the later callbacks.



Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 8 19:06:03 2006

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.