* Florent Daignière (NextGen$) <nextgens@freenetproject.org> [2007-03-07 13:59:28]:
> * Florent Daignière (NextGen$) <nextgens@freenetproject.org> [2007-02-28 14:52:43]:
>
> > * John Szakmeister <john@szakmeister.net> [2007-02-28 02:56:38]:
> >
> > > Ph. Marek wrote:
> > > >On Wednesday 28 February 2007 07:03, Malcolm Rowe wrote:
> > > >...
> > > >>So I'm thinking that somewhere in #3, the APR file buffer is written
> > > >>twice. I can think of only a few ways to achieve that effect, and none
> > > >>of them seem particularly likely:
> > > >...
> > > >
> > > >If that's repeatable and on a platform allowing for API traces (see eg.
> > > >strace on linux -- similar things exist for other OS), that could help a
> > > >lot - it would tell us the sequence of events.
> > >
> > > That's been a huge problem. Only 1 user has ever been able to repeat
> > > the problem (and he no longer can). Even then it was only after an
> > > undetermined series of commits. I've spent hours and hours trying...
> > > and have had no luck.
> > >
> > > -John
> >
> > I doubt I will be able to reproduce it : In spite I kept both the working
> > copy and the directory containing the repository, I haven't managed to
> > so far...
> >
> > Moreover, I have done a dump/load of the repository up to latest working
> > version and sucessfully commited the *same* patch using the *same*
> > client software.
> >
> > NextGen$
>
> Someone reproduced it yesterday on the same repository (same server,
> same version of apache-mpm-worker, same client software : subclipse
> 1.0.3 : an old version of javaSVN) attempting to commit a different
> patch from a different working copy.
>
> I have enclosed the revision file to this mail in case it helps and will
> ask our commiters to update their client software.
>
> NextGen$
Today I have encountered an other problem with the same repository :
on revision 12150 svnlook (started from the post-commit hook)
complained about :
"svnlook: Decompression of svndiff data failed"
http://archives.freenetproject.org/message/20070315.215906.f3661837.en.html
Then I managed to commit r12151 sucessfully, and svnlook managed to do
its job on it for some time ; a commit mail got genarated !
http://archives.freenetproject.org/message/20070315.221857.0d594b69.en.html
and since then I can't access the repository anymore... errors and symptoms
are different from last time... but the result is the same : the repository
is unavailable. The client software has been updated to subclipse 1.2.0 in
the meantime.
Apache's logs report :
[Thu Mar 15 22:23:21 2007] [error] [client 208.181.82.58] Provider encountered an error while streaming a REPORT response. [500, #0]
[Thu Mar 15 22:23:21 2007] [error] [client 208.181.82.58] A failure occurred while driving the update report editor [500, #185005]
[Thu Mar 15 22:23:21 2007] [error] [client 208.181.82.58] Decompression of svndiff data failed [500, #185005]
Here are links to revision files in case it helps:
http://emu.freenetproject.org/~nextgens/12150
http://emu.freenetproject.org/~nextgens/12151
Apache and mod_dav_svn are the only frontend configured.
nextgens@emu:~$ svn --version|head -1
svn, version 1.4.2 (r22196)
nextgens@emu:~$ svnlook --version|head -1
svnlook, version 1.4.2 (r22196)
nextgens@emu:~$ svnadmin --version|head -1
svnadmin, version 1.4.2 (r22196)
nextgens@emu:~$ dpkg -l libapache2-svn |grep ii
ii libapache2-svn 1.4.2dfsg1-2 Subversion server modules for Apache
nextgens@emu:~$ dpkg -l apache2-mpm-* |grep ii
ii apache2-mpm-worker 2.2.3-3.3 High speed threaded model for Apache HTTPD 2
SMART doesn't report any hard-drive error (I know that's not a proof it's
not faulty) and the server has 98 days of uptime... There is no obvious
kernel oops in logs nor complain about filesystem corruption...
I wonder if I'm really (un)lucky or if the hardware is to blame.
NextGen$
Received on Fri Mar 16 02:22:34 2007