On Thu, Nov 25, 2010 at 01:31:52PM +0530, Rajesh Menakath wrote:
> Hi,
>
>
>
> Recently we upgraded our svn server/client from 1.6.2 to 1.6.13, and
> since then, we are encountering the following error when a user tries to
> checkout/update a svn resource, where he has the required access (both
> read and write).
>
>
>
> svn: REPORT of '/svnrepository/!svn/vcc/default': 200 OK
> (http://10.1.121.199 <http://10.1.121.199/> ) -> this was with http
> protocol, and found the below errors in apache error logs:
>
>
>
> [Tue Nov 16 19:57:07 2010] [error] [client 10.1.128.18] Provider
> encountered an error while streaming a REPORT response. [500, #0]
>
> [Tue Nov 16 19:57:07 2010] [error] [client 10.1.128.18] A failure
> occurred while driving the update report editor [500, #185005]
>
> [Tue Nov 16 19:57:07 2010] [error] [client 10.1.128.18] Decompression of
> svndiff data failed: size too large [500, #185005]
>
>
>
> When I tried to do the same activity with svn protocol, I got the below
> error:
>
>
>
> svn: Decompression of svndiff data failed: size too large
>
>
>
> The weirdest part is that, it checks out the folder, but not the
> contents of the folder, and then throws the error mentioned (for both
> svn and http protocol).
>
>
>
> When I tried to checkout all the files in the subjected folder, with the
> help of svnlook (svnlook -r <last_modified_rev_on_that_folder> cat
> repository_path file_path > testfile), I got the same error for one of
> the file.
>
> svnlook: Decompression of svndiff data failed: size too large
>
>
>
> I could re-produce the error with both command line svn client, and
> tortoise svn and in both windows (xp service pack 3), and linux (RHEL5)
> environments. As mentioned earlier, both of our client and server are
> 1.6.13.
>
>
>
> Please confirm, if this is a bug or not, and suggest a way forward, and
> let me know if you need any more info.
>
>
>
> We could resolve the issue here for the time being, by deleting the
> resource, and re-committing the same (luckily the user, who made the
> last change, still had a working copy).
>
>
>
> PS: posted the same at users mailing list, and confirmed that it's a
> bug, possibly related to a known bug.
This is likely related to the security fix made in 1.6.4.
From the CHANGES file:
Version 1.6.4
(06 Aug 2009, from /branches/1.6.x)
http://svn.apache.org/repos/asf/subversion/tags/1.6.4
User-visible changes:
* fixed: heap overflow vulnerability on server and client
See CVE-2009-2411, and descriptive advisory at
http://subversion.apache.org/security/CVE-2009-2411-advisory.txt
I guess you have a corrupt revision file in the repository which
contains an invalid delta size field somewhere.
Can you check the integrity of your repository with svnadmin verify?
See also this script which you can use to try to detect and repair broken
revisions:
https://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side/fsfsverify.py
See also this attachment which contains a unix shell script that you can
use to more easily run fsfsverify.py on all revs in a repository:
http://svn.haxx.se/users/archive-2010-09/att-0122/verify-revisions.sh.txt
Stefan
Received on 2010-11-25 13:20:09 CET