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

Re: TSVNCache process eating all the available CPU

From: Jacques Lemire <Jacques.Lemire_at_gmail.com>
Date: Tue, 1 Jul 2008 08:45:01 -0700 (PDT)

> I doubt it has something to do with SUBST drives, but of course I can't
> be sure.
>
> * What are the full paths that are constantly checked by the cache?
> * what are the svn status of each of these files? (use
> check-for-modifications dialog)
> * are svn:externals folders present?
>

I am sorry I did not answer sooner. I had done some more testing the
next day so I could have steps to reproduce the problem. I had
narrowed it down to the fact that you needed to have a working copy on
the root of a drive - subst or not, with the .svn folder directly at
the root - with at least one versioned subfolder to experience it.
This was getting harder to explain and I was busy at work, so I
decided to try to debug it by myself when I got some time; it happened
that I did this morning.

I only have VS2005 and I did not have time to install all the deps for
SVN, so I had to fiddle with the old 1.4.x project files, grab a few
header files from the web and generate my libs from the collabnet
binaries of 1.5, so my setup is not clean, but TSVNCache.exe compiles
and runs in debug mode. I was able to reproduce the problematic
behavior. It seems my subst drive's root "L:" was getting added to the
watch list (AddDirectoryForUpdate) on every loop of the crawler, which
seemed to explain the strange behavior I could see in FileMon.exe and
the CPU problem I was experiencing when I am using my big WC as a
subst drive.

Digging a bit deeper, I saw that there was a child entry with
forwardslashpath="L:" under my "L:/" directory entry. This led me to
check how children are added to a cache entry, which is by using a
callback on the svn call which does return "L:" without the slash.
This callback uses CTSVNPath::SetFromSVN to create the entry. This
method does not call CTSVNPath::SetFwdslashPath, for performance
reasons I guess, which usually adds the ending slash to local root
paths. It even has the comment: // Subversion 1.5 fixed the problem
with root paths, but now it expects a slash for root paths.

However, since the cached parent (baton) was created using
CTSVNPath::SetFromWin which does add the backslash, the check "if(!
svnPath.IsEquivalentToWithoutCase(pThis->m_directoryPath))" that
prevents adding a folder as a child of itself fails in
CCachedDirectory::GetStatusCallback. Mayhem ensues.

Solution: sanitize local root paths every time a CTSVNPath is created.
I will propose a patch which fixes the problem based on the 1.5.0 tag.
Of course, you may ignore it entirely if you prefer to do the fix
yourself.

I do not regularly post to mailing lists, so excuse me if too many or
too few details were given in this message.
Jacques Lemire

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: dev-help_at_tortoisesvn.tigris.org
Received on 2008-07-01 17:51:23 CEST

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

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