[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS Checkout Fails

From: Mark D. Baushke
Subject: Re: CVS Checkout Fails
Date: Thu, 20 Feb 2003 00:14:39 -0800

Christopher Hollow <christopher.hollow@cgi.com> writes:

> Hi Folks...
>    Having some problems with CVS.  I'm running a pserver with v1.11.5
> wrapped with cvsd on FreeBSD 4.7.  Context: I have a number of people
> in my department using TortoiseCVS to download the repository to
> maintain project documentation (Word files).
> Most of the time the process goes off without a hitch.  About once
> every five or ten times, the checkout fails at a random spot in the
> download with the following error:
> ...
> U san/Unit.and.Integration.Testing/Bell SAN Storage Unit-Integration
> Testing Strategy.doc
> U san/docs/Auto Mgr script dev.pdf
> cvs [server aborted]: received broken pipe signal
> cvs checkout: warning: unrecognized response `cvs in free(): warning:
> chunk is already free' from cvs server
> cvs: [checkout aborted]: end of file from server (consult above
> message if any)
> Error, CVS operation failed

The above seems to indicate that the cvs server is printing the line

  'cvs in free(): warning: chunck is already free'

on stderr. See /usr/src/lib/libc/stdlib/malloc.c for the two calls to
wrtwarning() that can generate this message -- one from irealloc() and
the other from free_bytes().

My guess is that this means that the free() function is somehow being
called twice with the same pointer. It would be very useful if you could
help to pinpoint the warning. The only easy way to do this is to force
cvs to abort by setting malloc_abort using the environment variable
MALLOC_OPTIONS and a value of "A" ... you will likely need to create
a wrapper script around cvs for this purpose on your server machine

   % cat <<EOF >/usr/local/bin/cvs.debug
   exec /usr/bin/cvs ${1+"$@"}
   % chmod +x /usr/bin/cvs.debug

and then on your client machine using something like:

   export CVS_SERVER=/usr/local/bin/cvs.debug
or setenv CVS_SERVER /usr/local/bin/cvs.debug

and running your test untail you get a failure and hopefully a core

Be advised that when cvs does core dump, whatever directories it was
processing will now have stale CVS lock files that you will need to
remove 'manually'. (I can provide you with a quick perl script that will
find stale locks and try to remove them if you want to e-mail me
directly to get the script).

After you have the core file, you will need to figure out which free()
was being called in a duplicate manner and report back to this list if
you are not able to track the problem any further.

> I do a checkout on the directory again immediately after and it
> downloads the rest of the files and all is good.  Scoured the lists
> but didn't turn anything up...Any thoughts?  Need more info?  Thanx!
> -- 
> Christopher Hollow - Technical Consultant
> Infrastructure & Technology Support

        Good luck,
        -- Mark

reply via email to

[Prev in Thread] Current Thread [Next in Thread]