subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Varfolomeev <>
Subject Almost repetitive repository corruption
Date Sun, 29 Dec 2013 22:00:18 GMT
Hi all,

I’ve just ran into a weird bug which damaged my svn repository. I still 
don’t understand what exactly was wrong, so, I don’t know how to 
describe it in a clear and simple manner, sorry… I’ll just try to describe 
all the symptoms I’ve experienced. I’ll use real file names, since I 
wasn’t able to reproduce this bug on synthetic test repository. 

Most simple single-user, single-PC setup. Local repository. 
First svn version: “Subversion command-line client, version 1.8.5.”.
Windows 7 x64
Antivirus: Kaspersky Endpoint Security 10

The story began, when I ran into some sort of error message, while 
trying to commit r3349.
After a bit of struggling, I’ve realized, that my repository got broken 
after previous commit (r3348). Nasty thing is that previous commit 
finished without any error message. 

**svn verify**
Output ends like this:
* Verified revision 3346.
* Verified revision 3347.
svnadmin: E160004: 
Corrupt node-revision '4d-610.2-2392.r3348/35659066'
svnadmin: E160004: Found malformed header '' in revision file

**svn checkout**
When I try to checkout a new working copy, I receive similar 
Corrupt node-revision '4d-610.2-2392.r3348/35659066'
Found malformed header '' in revision file

**svn Repository Browser**
When I navigate to
 in tortoise svn repository browser, I see the same error message:

Corrupt node-revision '4d-610.2-2392.r3348/35659066'
Found malformed header '' in revision file

Here’s a screenshot: 

Luckily, I have a full backup (r3337). I’ve manually repeated all my 
commits up to r3347 and verified that at this state repository is OK.

Next, I’ve tried to reproduce the bug:

1.	Firstly (“try1”), I’ve repeated same Matlab commit script 
        (Matlab simply calls svn, just like from cmd). And… «success» 
        - same bug again! 

2.	Secondly (“try3”), I’ve managed to reproduce the bug using 
        only windows cmd commands.

3.	Thirdly (“try4” and “try5(0)”), I wrote a bat-script to 
        reproduce the same actions.

I’ve compared 
file for different “tries”:  (initial bug is designated as “try0”) and 
discovered a single interesting thing:
each “3348” file has a long sequence of zero-bytes:

•	try0: 0x2201B0A to 0x2201FFF

•	try1: 0x2201000 to 0x2201FFF
       o	try0_vs_try1_p1: 
       o	try0_vs_try1_p2: 
       o	try0_vs_try1_p3: 

•	try3: 0x2201B11 to 0x2201FFF
       o	try0_vs_try3_p1: 
       o	try0_vs_try3_p2: 

•	try4: 0x2201000 to 0x2201FFF
       o	try0_vs_try4_p1: 
       o	try0_vs_try4_p2: 
       o	try0_vs_try4_p3: 

•	try5(0): 0x2201000 to 0x2201FFF (just like try4).
       o	try0_vs_try5(0)_p1: 
       o	try0_vs_try5(0)_p2: 
       o	try0_vs_try5(0)_p3: 

Moreover, try4 and try5 have only one single difference, two zero-
bytes, starting from 0x21F9FFE (in case of “try5(0)”): 

That’s all I have. 5 broken repositories. After that bug DISAPPEARED. 
Just like a UFO :) . I’ve launched the SAME script, with the SAME 
input data 10 more times (“try5(1)”,”try5(2)”…) – nothing – svn 
correctly commits r3348, resulting repository is valid:

•	svn verify is OK

•	I’m able to see contents of 
        in tortoise svn repository browser

•	svn checkout is OK.

When I compare “revs\3348” for “try4” vs “try5(1)” the ONLY 
difference is those long sequence of zero-bytes mentioned before:

•	try4_vs_try5(1)_p1: 

•	try4_vs_try5(1)_p2: 

The bat script, that resulted in error is quite straightforward. It simply 
copies several files. It might be not a good idea to copy modified file 
without committing it first, but still it should not result in error… The 
bat file (used in try4) is here: 
Another thing to mention is that size of files in 3348 commit is about 
250 Mbytes….
To my shame, my repository is both large (~30GB) and containing 
confidential data, so, I’m unable to share it :( .

All files mentioned above are in this folder: 

Mainly, I’ve just googled “svn: Corrupt node-revision”. It looks like 
this error message is quite common, but no one tried to understand 
it’s source. Though, there’s a “what was that?” question 
in [1](see link below). 
Moreover, it looks like no one experienced “repetitive” behavior…  
In some cases, issue was resolved by restoring revision files from 
backup[1], or using svn dump/load [3,4]. In one report [2], 
julian.foad <at> was using John Szakmeister's 
'' to analyze corruption. Though, it looks like in his case, 
corruption type was quite different. In one post [4], VinnyJames 
said: “we've seen this happen during heavy load”. 





1.	What was that? Any ideas? May it happen again?
2.	Any other interesting diagnostic info I can get from these 
3.	Should I re-post this to subversion mailing list also? Or is it,
        most probably, dependent on tortoise somehow? 
        Say, due to some caching?

I’ve already posted the text above on tortoise svn mailing list:

and received a suggestion to re-post it here:

I’m not subscribed and would appreciate being explicitly Cc:ed in any responses.

View raw message