Re: Error: Found malformed header in revision file

  I can't reproduce the issue, but we seem to be experiencing this issue too.

  Vital stats:
 * AIX 5.3
 * subversion server 1.3.2 (fsfs backend)
 * Apache 2.2.3
 * libapr-0.so.0.9.7
 * TortoiseSVN client (don't know the revision number of the software
that did the submit as the software was upgraded last week :(

   The user submitting the revision may have experienced a network
issue or something on the desktop. No errpt (AIX's native
hardware/software fault-logging facility) nor syslog messages were
found around that timeframe.

  In our case, the transaction (5653) appears to be truncated.
However, when doing an svnadmin verify REPO-NAME

* Verified revision 5650.
* Verified revision 5651.
svnadmin: Malformed representation header

   On casual inspection it *appears* that 5652 is okay, but I don't
know the backend concepts well enough to be able to construct a test
to verify my assumption. The next transaction (5653) is definitely
truncated, however. The 5652 transaction is obnoxiously large
(~42MB!) so I'm not including it here.

   It *appears* that the next transaction (5654) is the resubmit of
the 5653 transaction.

  The fsfsverify.py script by the kind soul known as John Szakmeister
allows us to truncate some entries, but it appears that my random
truncations to the transaction (a copy of the original transaction is
included in this e-mail) don't help my repository corruption issue. :(
    (The Shakespeare play using the same 1,000 monkeys + 1,000
keyboards approach isn't working so hot either. :)

    Can someone confirm that the issue that I'm experiencing is the
same root issue as this one (and doesn't just have the same symptom)?
My users are experiencing errors attempting to perform a checkout,
which may mean that my assumption about 5654 being a retry of 5653 may
be incorrect, but....

   Is it normal in cases of corruption for the svnadmin verify to
point to the next-next transaction's id rather than next transaction
id?

   Is it possible for me to create an empty transaction to null out
the bad effects of this corruption? If so, how do I accomplish this?
Is this the right thing to do?

>* 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$
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org