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

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

From: Ph. Marek <philipp_at_marek.priv.at>
Date: 2006-09-06 07:07:15 CEST

Hello everybody,

I'm currently investigating reproduceable coredumps in fsvs
(fsvs.tigris.org), when running over svn+ssh:// (but not when used with
file://).

You can look at the source file update.c I'm describing here:
http://fsvs.tigris.org/source/browse/fsvs/trunk/fsvs/src/update.c?rev=410&view=markup
Or you can reproduce the bug by running the self-tests over svn+ssh:
     make run-tests PROTOCOL=svn+ssh

-

When updating a file locally fsvs gets it via apply_textdelta, as usually.
Please take a look at the comment in up__apply_textdelta();

       /* 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.
        *
        * If we just do a apr_file_close(), we get the error EBADF
        * (bad filehandle), and would accordingly die.
        *
        * If we don't do it (and let apr pool cleanup close it), the
        * close may just fall into the next second, and our
        * (in up__close_file) cached ctime is wrong - so we'd mark this
        * entry as changed.
        *
        * One solution would be to do a apr_file_close(), and ignore EBADF;
        * this is a bit unclean.
        *
        * So we go the other route: we simply define a subpool, where we
        * allocate the handles in, and clear that later.
        * That has the additional advantage that the struct estat could
        * possibly be shrinked in the future. */

Using the subpool worked fine some time ago (2-3 months), tested with
file:// and svn+ssh://.

But now I get bug-reports (which I can reproduce) on apr_pool_clear(),
called by up__close_file(). In this pool are *only* the two filehandles.

Can somebody provide me with an idea what I could change in fsvs?
Is this a known (or previously worked-around) problem with remote
subversion repositories?

Regards,

Phil

-- 
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 Wed Sep 6 07:07:52 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.