Daniel Shahaf wrote on Wed, Jul 31, 2013 at 18:24:49 +0300:
> Philip Martin wrote on Wed, Jul 31, 2013 at 15:44:47 +0100:
> > Daniel Shahaf <danie...@elego.de> writes:
> > 
> > > Jan (CC'd) reported an odd problem on IRC today: he would get
> > >
> > >     Corrupt representation '537009 564 9641 0 
> > > 61d9000a8ccca3379173bbbbe0bb15bc'  [500, #160004]
> > >     Malformed representation header at 
> > > /swdev/ssd/CONVERSION/SVN/test/db/revs/537/537009:593
> > >
> > > *sometimes* when he ran 'update --parents' that pulled in
> > > a not-yet-in-the-wc file.  The errors went away after he restarted
> > > httpd.  The error log had an EPERM on rev-prop-atomics.mutex which may
> > > or may not be related.
> > >
> > > Now, that error is actually very odd:
> > >
> > > - "61d9000a8ccca3379173bbbbe0bb15bc" doesn't occur anywhere in the 
> > > filesystem
> > >   (rep-cache.db and db/revs/**/*)
> > 
> > Looking at the repository path ('CONVERSION' and 'test') and the fact
> > that the error vanished when httpd was restarted is it possible this
> > involved a temporary repository being replaced by another repository at
> > the same path with the same UUID.  If that happens I think apache may
> > have been using the in-memory cache associated with the old repository
> > when accessing the new repository.
> 
> You're right about the "same path and uuid" point (see
> svn_fs_fs__initialize_caches()).
> 
> That said, I tried to reproduce it by:
> 
> % ./davautocheck.sh --no-tests
> % ./basic_tests.py --url=http://localhost:3691 3
> % cd svn-test-work/repositories/
> % $svnadmin hotcopy basic_tests-3 c
> % $s import -q -mm =(echo before) $u/basic_tests-3/foo 
> % $s cat $u/basic_tests-3/foo
> before
> % mv basic_tests-3 before
> % mv c basic_tests-3
> % $s import -q -mm =(echo after) $u/basic_tests-3/foo  
> % $s cat $u/basic_tests-3/foo
> after
> 
> and I got the right answer.  Since I had "SVNCacheFullTexts On" in the
> config, I had expected the last 'cat' to return "before\n".  Why didn't
> it return "before\n"?

Never mind.  It reproduces when I run the first "cat" multiple times.
Probably because I use a forking MPM.

Reply via email to