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

Seeking help for "E000054: Error retrieving REPORT: Connection reset by peer"

From: Mojca Miklavec <mojca.miklavec.lists_at_gmail.com>
Date: Sat, 4 Jan 2014 23:08:09 +0100


We have a server running Fedora which has recently been upgraded to
version 20 and it's now running
    svn, version 1.8.5 (r1542147)

I have a bunch of repositories served over http protocol with public
read access and limited commit access.

Shortly after the upgrade a weird behaviour has been noticed. Running
"svn up" on the top level dir worked ok for me, but running
    svn co http://svn.myserver.net/myrepo/dirA
fails with

A dirA/subdir1
A dirA/subdir2
A dirA/subdir3
A dirA/subdir4
svn: E000054: Error retrieving REPORT: Connection reset by peer

The directory "dirA" contains one more file FILE.txt. Checking out any
individual "subdirN" works and the browser is able to display the
contents of dirA.

Trying to click on FILE.txt in the browser sometimes works (it
currently does) and sometimes shows an XML (like a few minutes ago,
but I'm unable to get it now), saying something similar to the error I
get in console***:

svn: E175002: Unable to connect to a repository at URL
svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on

svn: E160004: Additional errors:
svn: E160004: Corrupt node-revision '2-1.0.r137/330061'

(*** To be precise: this is the error I get after upgrading the
repository to the latest version of SVN, I didn't try to get to this
error before upgrading.)

The error.log in apache says just:

[<date>] [dav:error] [pid 3613] [client <ip:port>] Unable to deliver
content. [500, #0]
[<date>] [dav:error] [pid 3613] [client <ip:port>] Could not write
data to filter. [500, #175002]

I first tried if upgrading the repository would help in any way, so I did
    svnadmin dump oldrepo | svnadmin load newrepo
and checking the relevant revision r137 cited in the error all I see
is the following (nothing unusual):

------- Committed revision 136 >>>

<<< Started new transaction, based on original revision 137
     * editing path : dirA/FILE.txt ... done.
* Dumped revision 137.
     * editing path : dirA/subdir1/somefile ... done.

------- Committed revision 137 >>>

Checking out the same repository via http on the machine where the
repository itself is located works fine.

I'm using the same version of SVN (1.8.5) on Mac, but other svn
clients on other OSes have problems as well.

I tried checking the repository health with
    svnadmin verify /path/to/myrepo
and all revisions passed except for some weird error inbetween (the
file rev-prop-atomics.mutex is actually missing, but it isn't present
in any other repository either):

* Verifying repository metadata ...
* Verifying metadata at revision 1 ...
* Verifying metadata at revision 155 ...
svnadmin: E160052: Revprop caching for '/path/to/myrepo/db' disabled
because SHM infrastructure for revprop caching failed to initialize.
svnadmin: E000013: Can't open file
'/path/to/myrepo/db/rev-prop-atomics.mutex': Permission denied
* Verified revision 0.
* Verified revision 160.

I would appreciate any help or debugging hints. If necessary I can
share the repository URL (but I would prefer to share it off-list to
anyone interested in debugging). I can also try to debug myself, but I
need some instructions telling me what to check. I didn't manage to
find anything useful by googling the errors other than figuring out
that the error was part of the code to fix a memory leak

Thank you,
Received on 2014-01-04 23:08:41 CET

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

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