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 <s...@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. >
