Bert;
With thanks for your assistance, I believe I have a promising resolution to
try in the morning. I believe I have identified the revision at fault.
FYI
Yes, you are correct, Windows Server 2003.
Had a quick look at the event viewer.
Faulting application Apache.exe, version 2.0.55.0, faulting module
mod_dav_svn.so, version 1.4.3.23084, fault address 0x0000bcea.
I tried your suggestion of svn log.
When I ran this initially it also failed with the same error as TortoiseSVN
with the output stopping also at the infamous revision that TortoiseSVN
stopped at.
Further investigation using the revision option appears to confirm that it
is actually the prior revision which is the issue - not the one implied by
the text of the "Could not read chunk size:" error message.
I identified the revision by a combination of svn log and svnlook.
Svnlook showed me what files changed for a revision that svn log wouldn't
show anything for (just aborted see below).
This suggests that the issue has something to do with the content or size of
the text included as the log entry.
Is there a constraint on the size of text entry (I would assume it is quite
generous) or could an unintentional rogue character in the text cause an
issue?
As background, the original run of svn log before I mixed and matched with
svnlook:
svn: REPORT request failed on '/svn/!svn/bc/33600/.......'
svn: REPORT of '/svn/!svn/bc/33600/.............': Could not read chunk
size: An existing connection was forcibly closed by the remote host.
With the event viewer recording an entry as per that when using TortoiseSVN
Faulting application Apache.exe, version 2.0.55.0, faulting module
mod_dav_svn.so, version 1.4.3.23084, fault address 0x0000bcea
Kind Regards
Gavin
-----------------------------------------
Gavin Henderson
Senior Payments Specialist
| GFG Group Limited | PO Box 5825, Wellesley St, Auckland, New Zealand |
D: +64 9 966 7030 | T: +64 9 966 7041 | M: +64 21 174 1499 | F: +64 9
966 7070 | Skype ID: gavin.henderson.nzgh | <http://www.gfg-group.com/>
www.gfg-group.com |
This email and any attachments are confidential and intended exclusively for
the person to whom the email is addressed. If you are not the intended
recipient, do not read, copy, disclose or use the contents in any way.
Please notify us immediately by return email and destroy the email and
attachments. GFG Group does not accept any liability for any changes made to
this email or attachments after sending by GFG Group. You must scan this
email and attachments for viruses. The opinions expressed are not
necessarily those of GFG Group.
GFG Group accepts no liability for any loss, damage or consequence, whether
caused by our own negligence or not, resulting directly or indirectly from
the use of this email and attachments.
_____
From: Bert Huijben [mailto:bert_at_qqmail.nl]
Sent: Thursday, August 21, 2008 11:12 PM
To: 'Gavin Henderson'; users_at_subversion.tigris.org
Subject: RE: Could not read chunk size: An existing connection was forcibly
closed by the remote host: How to identify (assumed) revision causing issue
Hi Gavin,
Looking at the error code, my guess is your subversion server is on a
Windows machine.
It seems your Apache server process died with an access violation.
(3221225477 = 0xC0000005 = Access Violation). The error 'Could not read
chunk size' is one of the errors you might see if a connection is broken
abruptly.
I assume your event viewer contains a little bit more information than just
'Access Violation'. (We can't tell you more without that information
For your immediate needs:
You can always try running 'svn log' directly on the repository server with
svn log file:///d:/subversion/repositories/myrepos/
<file:///d:\subversion\repositories\myrepos\>
This eliminates the apache process and its buffering from the call.
svn log has a -r parameter that allows you to select a range of revisions.
Bert
From: Gavin Henderson [mailto:ghenderson_at_gfg-group.com]
Sent: donderdag 21 augustus 2008 12:45
To: users_at_subversion.tigris.org
Subject: Could not read chunk size: An existing connection was forcibly
closed by the remote host: How to identify (assumed) revision causing issue
Hello;
>>>Overview:<<<
Recently I started getting the error "Could not read chunk size: An existing
connection was forcibly closed by the remote host" when attempting to view
the log via TortoiseSVN upon one of my source lines.
Having viewed a few entries of the various user sites I believe, as I have
not changed any of the configuration files or versions of Apache,
TortoiseSVN, Windows or SVN this year, implies that I have a different issue
than what I have found so far. I did change the 'KeepAliveTimeout' parameter
from 15 to 500 as one resolution hinted - but this appeared to make no
difference (with the error occurring well prior to the original 15 seconds
limit).
When the issue first occurred the log entries listed implied a specific log
entry (revision) was the cause (or the one following not presented as part
of the response). Since then subsequent commits have been made that are
viewable similarly appearing to stop in a similar position in the expected
list as per the original occurrence.
On this basis, I have the intention to try and identify the revision I
assume is the cause of the problem and side step it by recreating the source
line and recreating the revision in question as required. To date (although
only started this afternoon) I still have not identified the revision and
this email aims to ask whether anyone has a short cut or wishes to suggest I
am on the wrong track and an appropriate course of investigation).
I have completed a svnadmin verify with no issue identified, with the
Apache2 error log containing the following
[Thu Aug 21 21:55:30 2008] [notice] Parent: child process exited with status
3221225477 -- Restarting.
but no apparent related information.
>>>Request for suggestions<<<
Due to imminent deadlines I am obviously interested in any suggestions as to
how I can easily list out the revisions (preferably by range) with
appropriate information (source line, author, revision, date) without having
to run once for each - but obviously will if needed. My intent is to create
a script to run svnlook after choosing my parameters for each of the
revisions in my suspect range and try to identify the one of issue around
where the log entries list mentioned above terminates for the source line in
question. To track it down within the range even with this information may
be time consuming.
Is there another verification process other than 'svnadmin verify' that
could assist or that I should run to ensure stability of the repository?
Does anyone have any suggestions as to potential causes of this issue that I
could try to eliminate in the future?
Can some-one advise what "Could not read chunk size" actually means?
My intention is to try and identify the culprit - appreciate what it was
about - create a replacement source line excluding the one causing the issue
(etc).
The main aim of my course of action is to rescue the log in a useable form -
as I have the source and appear to be able to fully checkout the source line
without issue.
Thank you.
Kind Regards
Gavin
-----------------------------------------
Gavin Henderson
Senior Payments Specialist
| GFG Group Limited | PO Box 5825, Wellesley St, Auckland, New Zealand |
D: +64 9 966 7030 | T: +64 9 966 7041 | M: +64 21 174 1499 | F: +64 9
966 7070 | Skype ID: gavin.henderson.nzgh | <http://www.gfg-group.com/>
www.gfg-group.com |
This email and any attachments are confidential and intended exclusively for
the person to whom the email is addressed. If you are not the intended
recipient, do not read, copy, disclose or use the contents in any way.
Please notify us immediately by return email and destroy the email and
attachments. GFG Group does not accept any liability for any changes made to
this email or attachments after sending by GFG Group. You must scan this
email and attachments for viruses. The opinions expressed are not
necessarily those of GFG Group.
GFG Group accepts no liability for any loss, damage or consequence, whether
caused by our own negligence or not, resulting directly or indirectly from
the use of this email and attachments.
Received on 2008-08-21 15:03:05 CEST