Stefan Küng wrote:
>> see it if access is via tortoiseSVN's repobrowser. The way to
>> reproduce the crash is repeatedly and randomly jump all over the repo
>> browser window clicking on folders to open them up. I can crash the
>> svnserve in as little as three clicks and at worst it takes about
>> 20-30 clicks. I know that means it's probably TSVN, but I also fail to
>> see why the
>
>
> It simply *can't* be TSVN:
> 1. it's svnserve that's crashing, not TSVN. TSVN has bugs of its own :)
> 2. TSVN uses the Subversion library for all repository/working copy
> operations. We don't do anything ourselves here.
Yeah, upon reflection last night I'd come to the same conclusion. It
would appear (and that's not to say its the case) that svnserve may be
crashing because TSVN opens several connections at the same time. I've
verified using Ethereal that the conversations with svnserve are
complete (and interlaced acording to the ethereal data); that is the
crash does not occur within a conversation, but it would appear that
svnserve dies just after a conversation has occurred.
It would also appear that svnserve is not cleaning up something nicely
when hit by multiple connections (*), but I guess it doesn't rule out
the possibility of a problem with the database either. However, against
that is the fact that the repobrowser induced crash can occur at
different points in the 'tree', so it wouldn't appear to be related to
location.
(*) Given it's a server I would have thought that the cleanup code for
the converstaion would be quite stable, perhaps this is a result of some
database call not being closed out? To do with v4.3 of the BDB?
> Try
> svn ls -v "svn://x.x.x.x/me"
>
> the repobrowser always calls 'ls' with the '-v' switch (actually, we're
> calling svn_client_ls(), not the CL client, but you get the idea).
Tried this, 50 calls from a batch program running on two different
systems (one my dev machine, the other the server itself), effectively
spamming svnserve. I received a fatal error once and had to do a
recovery. The very next test produced this error:
svn: Berkeley DB error for filesystem E:/Svn/repos/me/db while opening
'nodes' table:
Resource device
and this
svn: Berkeley DB error for filesystem E:/Svn/repos/me/db while opening
'nodes' table:
Resource device
but only while both batch files were running. These errors did not
suggest a reovery, but I did one anyway before running the test again.
After a few of the nodes errors I finally got:
svn: Can't connect to host '192.168.0.128': No connection could be made
because the target mach
ine actively refused it.
Indicating that svnserve had crashed. Lookis like the crash is entirely
on the svn side.
cheers, Alex.
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Fri May 26 02:58:23 2006