Re: dreaded "Decompression of svndiff data failed" question

 On Thu, 23 Jun 2011 22:34:54 +0200, Stefan Sperling wrote:
> On Thu, Jun 23, 2011 at 08:50:05AM +0200, martin wrote:
>> Hi all,
>>
>> I've searched the list and could not find an answer to this.
>>
>> I've run into the dreaded "Decompression of svndiff data failed"
>> problem.
>>
>> Running http://www.szakmeister.net/fsfsverify/utility trying to fix
>> it I end up with a string of errors.
>>
>> So far I've seen:
>> ------------
>> - Error InvalidCompressedStream: Invalid compressed instr stream at
>> offset xxxx (Error -3 while decompressing: incorrect header check)
>> - Error InvalidCompressedStream: Invalid compressed data stream at
>> offset xxxx (Error -3 while decompressing: incorrect data check)
>> - Error InvalidWindow: The window header at offset xxx appears to be
>> corrupted
>> ------------
>
> We have so far never been able to pin down the cause of such
> corruption problems. It could be a bug in Subversion (and you should
> be upgrading to avoid the ones that are already known), but it might
> just as well be a bug in some dependency Subversion is using (such as
> APR),
> or a bug in your operating system, or your disk controller or the
> disk
> itself having problems.
>
> If you'd like to share your corrupt revision file (privately if you
> like)
> I'd be happy to take a look at it.
> If you are lucky it's an instance of this problem:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3705
> fsfsverify can fix some instances of this but not all.
> I've fixed two such files manually so far which fsfsverify could not
> fix.
>
> And even if it's something else, maybe we can figure out what went
> wrong.
> And maybe if we see enough corrupt revision files we'll eventually be
> able to pin it down to a bug in Subversion and fix it.
>
> But the last time I was looking at a corrupted revision file it
> simply
> contained corrupted zip data. zlib could not decompress it anymore
> and nobody knew why. The file was simply broken and we could not
> reconstruct it within reasonable effort.
>
> So keep backups :)

 Thanks for all the feedback so far,

 It's an old legacy system I inherited and the earlier guys only did a
 hotcopy not verify, so on further investigation I found about 20 errors
 in total in all it's history (fatal ones).

 It's about half / half with the above error and else the checksum
 error. The latter I can at least get to a stage where I can 'skip' it
 and re-commit again.

 For the former I'm stuck with fsfsverify just looping, and the error
 revision had a zip file added to it just like yours.

 I'll have a look into it and see if I can share the corrupt file.

 Regarding hardware it's on a virtual server which hosts about 20 other
 guests (and none of those have any data corruption), so I don't think
 it's hw-related. It's not highly loaded nor are the VM host or any
 guests.

 It's running off CentOS and have about 66k revisions. I've tried to see
 if I can find a pattern in it, and from the about 20 errors one certain
 user is either the one comitting or the error occur when others merge in
 his data. I have 2 out of 20 errors which does not follow this pattern.
 Of course it could just be coincidence, but seems rather suspecious to
 me. Also, this guy was absent from ~3000 forthgoing revisions and no
 errors in the meantime, then he started comitting again and at exactly
 the same time errors started to occur (not his own commit but when
 someone merged his in later). He's using windows 7 but doesn't seem to
 have any malware or the like on his system.

 Also, there is no [seemingly] clear pattern about it having to be a
 zip-file. Ordinary text-commits seem to trigger it as well, although the
 majority is because of zip-files.

 I'm mostly inclined to believe it's something network-related, but the
 'evidence' I have point in another direction.

 Again, I appreciate your time thinking about this,

 /Martin

 If I make any progress I'll be sure to let you guys know.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.