[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On update: end of file from server, no messages given
From: |
Derek Robert Price |
Subject: |
Re: On update: end of file from server, no messages given |
Date: |
Fri, 13 Jun 2003 11:53:49 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 |
Keane, Patrick wrote:
Hello list,
I am trying to track down this issue that we are seeing recently with larger
files:
cvs update -P gabriel60ProjectPlan.xls (in directory
D:\src\Documents\gabriel\projectManagement\)
U ProjectPlan.xls
cvs [update aborted]: end of file from server (consult above messages if
any)
Is there a preferred method for debugging the server messages when an error
occurs? I am assuming (perhaps incorrectly) that the server is crashing
halfway through file transfer (maybe SEGV). What I need to understand is
the reason. We seem to have sufficient amounts of physical memory, and an
abundance of virtual memory that remains unused during the transfer (watch
cat /proc/meminfo shows this).
Before I make some recommendations as to how we will resolve this, I need to
get a better understanding of what the cause might be. How to best debug
the server is my first question.
I think RedHat 7.3 still leaves core files around by default, but later
versions default to a `ulimit -c 0' (Leave core files only if they are
smaller than zero bytes). If your server really crashed, there should
be a tmp directory in /tmp/cvs-serv* where `*' is a randomly generated
set of characters. To get the correct server dir, if there is more than
one present (they normally should not be left hanging around), delete
all the old ones, reproduce your bug, then look in /tmp and there should
only be one. The core file should be in it.
If you can't find the dir or the core file, you might consider setting
CVS_SERVER_SLEEP on the server, running your offending client command,
then connecting a debugger.
Setting CVS_CLIENT_LOG on the client will generate a log of all the data
going to and from the server, if you would find that useful.
Both of these environment variables are documented in the Cederqvist:
<http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_19.html#SEC180>.
Moving on, here is the environment we are working with leading to my second
question:
Server is Redhat Linux 7.3 with kernel v2.4.18-3 and CVS:
Concurrent Versions System (CVS) 1.11.1p1 (client/server)
(via Redhat package cvs-1.11.1p1-8.7)
Client is Windows 2000 or Windows XP with CVS:
Concurrent Versions System (CVSNT) 2.0.2 (client/server)
(via WinCVS version 1.3)
My second question is, is this a valid setup? Several users have recently
upgraded their environments to WinCVS 1.3, which contains CVSNT version of
the client at 2.0.2 level. I don't recall this error being reported with
users who are using WinCVS 1.2, which was packaged with:
Concurrent Versions System (CVS) 1.11 (client)
I don't know much about CVSNT. You might consider upgrading to 1.11.6
or 1.12.1 on your Linux server. Many bugs have been fixed since 1.11.1p1.
Derek
--
*8^)
Email: derek@ximbiot.com
Get CVS support at <http://ximbiot.com>!
--
A burp is not an answer.
A burp is not an answer.
A burp is not an answer...
- Bart Simpson on chalkboard, _The Simpsons_