You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Dave_Thomas mailing lists <da...@peoplemerge.com> on 2006/12/14 01:28:30 UTC
Decompression of svndiff data failed
Aren't repositories and/or dumps portable between Windows and Linux? If so,
should I file a bug report on this?
I'm loading a 7GB dumpfile with svn 1.4.2 built from tarball, deps,
apr-1.2.8 on RHEL4. The original repository was originally created and
dumped using 1.4.0 svn client on windows. It was then dumped again with the
updated 1.4.2 Windows binary release, with the same result.
Below are the errors.
$ svnadmin verify repo_created_on_windows
* Verified revision 0.
svnadmin: Decompression of svndiff data failed
$ svnadmin load repodir < my_8GB_dumpfile_created_on_windows
<<< Started new transaction, based on original revision 1
* adding path : source/somefile
(... several hundred large files succeed)
* adding path : source/someotherfile
svnadmin: Checksum mismatch, file '/source/yetanotherfile':
expected: 43e6daaaa45805a2cf8c3b65d9198086
actual: 7ddf690e85dcd6466daec1204fb1197c
* adding path : source/yetanotherfile ...
What's particularly odd is that every time you run the svnadmin load
command, it fails on different files.
The svnadmin 1.4.2 load and verify both work fine on Windows.
Is the Windows subversion binary linked against DLLs I should be aware of,
for example zlib?
I've attached the config.log for svn 1.4.2, apr, apr-utils
Here is a recent, related thread:
On 11/28/06, Eugene Krasikov <zh...@ngs.ru> wrote:
>
> Hello.
>
> I use svnsync to mirror my repo. All worked fine for a while, but
> today I get error
> svnsync: REPORT request failed on ' http://192.168.77.17/svn'
> svnsync: REPORT of ' http://192.168.77.17/svn': 200 OK
> (http://192.168.77.17 )
> every time I try to do svnsync sync.
>
> There's
> [Tue Nov 28 16:33:03 2006] [error] [client 192.168.77.85] A
> failure occurred while driving the update report editor [500,
> #160005]
> [Tue Nov 28 16:33:03 2006] [error] [client 192.168.77.85] Target
> path does not exist [500, #160005]
> in Apache's error log.
>
> I found out that I got these errors not only from snvsync, but also
> from svn co, svnadmin dump, etc.
>
> This happened after we commited a pack of files in the repo in the
> separate subfolder, all operations fail only if they access that
> subfolder on that commit revision. If I try to access other files, all
> work fine.
>
> I tried to use file:// instead http:// and got "Decompression of
> svndiff data failed"
>
> svnadmin verify says the same.
>
> I found "Decompression of svndiff data failed" message only in one
> file in sources - /libsvn_delta/svndiff.c - in the zlib_decode
> function. So, probably data in the repository in the file for this
> revision somehow corrupted during or after commit? Am I right or
> there's another reason of these errors (I googled, but what I found is
> not my case)?
>
> And the most important thing. How can I make my repo consistent back
> now? I can't even make svnadmin dump and erase that revision from dump
> file...
>
> Thanks,
> Eugene Krasikov
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: Decompression of svndiff data failed
Posted by David Glasser <gl...@mit.edu>.
On 12/16/06, Dave_Thomas mailing lists <da...@peoplemerge.com> wrote:
> I discovered the root cause of the problem. The system had BAD RAM !!! On
> a fresh system with new ram, identical OS and svn build process, loads,
> restores, commits, and everything else works flawlessly!
Sorry about the RAM, but that's nice to know for us!
--dave
--
David Glasser | glasser@mit.edu | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Decompression of svndiff data failed
Posted by Dave_Thomas mailing lists <da...@peoplemerge.com>.
I discovered the root cause of the problem. The system had BAD RAM !!! On
a fresh system with new ram, identical OS and svn build process, loads,
restores, commits, and everything else works flawlessly!
The big clue was when I ran the svn verify multiple times it failed in
completely different spots. An even bigger clue was when I ran md5sum on
large ISOs, it calculated a different number every time. Memtest86+
confirms this.
Dave
On 12/16/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>
> On 12/16/06, Dave_Thomas mailing lists <da...@peoplemerge.com> wrote:
> > I hope to God that what we're seeing is an OS or hardware issue. Anyone
> > have any ideas?
>
> Is it possible for you to post the dumps somewhere? -- justin
>
Re: Decompression of svndiff data failed
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 12/16/06, Dave_Thomas mailing lists <da...@peoplemerge.com> wrote:
> I hope to God that what we're seeing is an OS or hardware issue. Anyone
> have any ideas?
Is it possible for you to post the dumps somewhere? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Decompression of svndiff data failed
Posted by Dave_Thomas mailing lists <da...@peoplemerge.com>.
I thought this is just an dumpfile load issue. So I created a linux repo
from scratch and we've been loading it up from our Windows clients (Tortise
+ 1.4.2). Now we're seeing this:
sudo svnadmin verify .
* Verified revision 0.
* Verified revision 1.
* Verified revision 2.
svnadmin: Malformed header
sudo svnadmin verify .
* Verified revision 0.
* Verified revision 1.
* Verified revision 2.
* Verified revision 3.
* Verified revision 4.
svnadmin: Decompression of svndiff data failed
sudo /usr/bin/svnadmin verify .
* Verified revision 0.
* Verified revision 1.
* Verified revision 2.
* Verified revision 3.
* Verified revision 4.
* Verified revision 5.
* Verified revision 6.
svnadmin: Checksum mismatch while reading representation:
expected: 21eceb49b8bea18959651e2d9e1332b4
actual: 1230bcc2e1c99f592bc57b4c6852b069
sudo /usr/bin/svnadmin verify .
* Verified revision 0.
* Verified revision 1.
* Verified revision 2.
* Verified revision 3.
* Verified revision 4.
svnadmin: subversion/libsvn_delta/text_delta.c:529:
svn_txdelta_apply_instructions: Assertion `tpos + op->length <=
window->tview_len' failed.
I hope to God that what we're seeing is an OS or hardware issue. Anyone
have any ideas?
Dave
On 12/15/06, Dave_Thomas mailing lists <da...@peoplemerge.com> wrote:
>
> I sure do have the dumpfile :) The MD5 sums do indeed match on Linux.
>
> On 12/15/06, David Glasser <gl...@mit.edu> wrote:
> >
> > On 12/13/06, Dave_Thomas mailing lists <davelist@peoplemerge.com >
> > wrote:
> > > Aren't repositories and/or dumps portable between Windows and
> > Linux? If so,
> > > should I file a bug report on this?
> > >
> > > I'm loading a 7GB dumpfile with svn 1.4.2 built from tarball, deps,
> > > apr-1.2.8 on RHEL4. The original repository was originally created
> > and
> > > dumped using 1.4.0 svn client on windows. It was then dumped again
> > with the
> > > updated 1.4.2 Windows binary release, with the same result.
> >
> > I'm not familiar with the errors you've reported; they definitely seem
> > to be a concern.
> >
> > Do you still have a copy of the dumpfile both on Windows and on RHEL?
> > Before people dive into debugging, let's rule out things like an error
> > in transferring the file. Can you run an md5 sum on the dumpfile on
> > both platforms and make sure that it's the same? (Note that dumpfiles
> > look vaguely like text files, but are actually binary.)
> >
> > --dave
> >
> >
> > --
> > David Glasser | glasser@mit.edu | http://www.davidglasser.net/
> >
>
>
Re: Decompression of svndiff data failed
Posted by Dave_Thomas mailing lists <da...@peoplemerge.com>.
I sure do have the dumpfile :) The MD5 sums do indeed match on Linux.
On 12/15/06, David Glasser <gl...@mit.edu> wrote:
>
> On 12/13/06, Dave_Thomas mailing lists <da...@peoplemerge.com> wrote:
> > Aren't repositories and/or dumps portable between Windows and Linux? If
> so,
> > should I file a bug report on this?
> >
> > I'm loading a 7GB dumpfile with svn 1.4.2 built from tarball, deps,
> > apr-1.2.8 on RHEL4. The original repository was originally created and
> > dumped using 1.4.0 svn client on windows. It was then dumped again with
> the
> > updated 1.4.2 Windows binary release, with the same result.
>
> I'm not familiar with the errors you've reported; they definitely seem
> to be a concern.
>
> Do you still have a copy of the dumpfile both on Windows and on RHEL?
> Before people dive into debugging, let's rule out things like an error
> in transferring the file. Can you run an md5 sum on the dumpfile on
> both platforms and make sure that it's the same? (Note that dumpfiles
> look vaguely like text files, but are actually binary.)
>
> --dave
>
>
> --
> David Glasser | glasser@mit.edu | http://www.davidglasser.net/
>
Re: Decompression of svndiff data failed
Posted by David Glasser <gl...@mit.edu>.
On 12/13/06, Dave_Thomas mailing lists <da...@peoplemerge.com> wrote:
> Aren't repositories and/or dumps portable between Windows and Linux? If so,
> should I file a bug report on this?
>
> I'm loading a 7GB dumpfile with svn 1.4.2 built from tarball, deps,
> apr-1.2.8 on RHEL4. The original repository was originally created and
> dumped using 1.4.0 svn client on windows. It was then dumped again with the
> updated 1.4.2 Windows binary release, with the same result.
I'm not familiar with the errors you've reported; they definitely seem
to be a concern.
Do you still have a copy of the dumpfile both on Windows and on RHEL?
Before people dive into debugging, let's rule out things like an error
in transferring the file. Can you run an md5 sum on the dumpfile on
both platforms and make sure that it's the same? (Note that dumpfiles
look vaguely like text files, but are actually binary.)
--dave
--
David Glasser | glasser@mit.edu | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org