On Fri, Feb 07, 2014 at 11:18:36AM +0000, Phil Cornelius wrote:
> Stefan Sperling <stsp <at> elego.de> writes:
> > Using a binary file that had been committed to a revision that was
>
> > corrupt, we could construct a test case with simply committing this
>
> > file in a loop and running 'svnadmin verify' on the HEAD revision
>
> > right after. The corruption occurred in about 1 in 100 revisions.
>
> > Symptoms were like in http://subversion.tigris.org/issues/show_bug.cgi?
>
> id=3705
>
> > The commit itself succeeded so Subversion believed the data had been
>
> > committed fine. Only a subsequent 'svnadmin verify' found the problem.
>
> This seems such an edge case, are there any normal or regular conditions in
> which this corruption can occur?
The exact conditions are unclear.
It was reproducible only on two production machines at the client's
site. We tried to reproduce in a virtual machine as well, and failed.
The virtual machine was otherwise idle, however, and the production
machines were receiving a commit every few seconds.
It is possible that there are some concurrency/threading issues involved.
Sometimes the corruption would reproduce instantly when we started
out test script. Sometimes it took hundreds of test commits before
it occurred again. We couldn't reproduce it at will.
> Will it *only* happen if the revision you
> are commiting to is corrupt?
What do you mean? A revision doesn't exist before it is committed.
Subversion obviously didn't detect the corruption during the commit.
Only 'svnadmin verify' on already committed revisions showed that
corruption had occurred somewhere during the commit process.
> could it happen for regular source (text files)
Perhaps. I don't know.
> Reason I ask is that a quick trawl shows that subversion possibly defends
> against these earlier version of APR
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664451
That was one particular bug in APR which was worked around.
Subversion uses APR very extensively.
All file i/o operations Subversion does are made through APR.
There might have been other bugs causing similar issues.
> Do you understand why the corruption is occurring ?
I really have no more information than I've already shared.
I don't think it's worth trying to chase down the exact cause of
this problem. That's additional time spent on a problem already
been solved. Just update APR to a recent version if you're still
running APR 1.2.7.
Received on 2014-02-07 17:23:32 CET