Thanks for your response..
> What do you mean? A revision doesn't exist before it is committed.
You wrote:
> > Using a binary file that had been committed to a revision that was
> > corrupt
That sounded like a pre-condition for the bug. 'had been' i.e. were you
able to reproduce this on a brand new known good repository. Or was the
repository already in some kind of corrupt state.
I am with you about getting off the old APR.. but I want to understand if
this is urgent.. or could perhaps wait 6 months as we plan a move to a
newer RHEL.
On 7 February 2014 16:22, Stefan Sperling <stsp_at_elego.de> wrote:
> 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 19:42:02 CET