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 <danielsh_at_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.
Received on 2013-07-31 17:30:40 CEST