[Top][All Lists]

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

Re: Lock files in version 1.11.11

From: Mark D. Baushke
Subject: Re: Lock files in version 1.11.11
Date: Tue, 13 Jan 2004 23:50:33 -0800

Hash: SHA1

Zanabria, Moises <address@hidden> writes:

> Guys,
> I'm trying to figure out what's what my problem is,  since I upgraded my cvs
> binary I'm getting a bunch of cvs lock files and those are leaving in the
> repository.
> My last cvs server version was 1.11.5 and I've just upgrade to the latest,
> in the past I was working with CVS 1.11.5 in the server and cvs 1.11 client
> for  several Unix flavors, but since I've migrated the binary to 1.11.11 and
> use the same (cvs 1.11) in the cvs co process or commit process the lock
> file is not going away.
> please let me know if that particular issue would solve if I upgrade the
> client as well..if so what about the WinCvs Binary??

I doubt it.

> I ran the a trace and this is what I got:
> The first time has been succeeded.  The second case failed.
> S-> system('/local/cvscore/bin/' '/tmp/cvsBfxwCc')
> S-> rename(CVS/Entries.Backup,CVS/Entries)
> S-> unlink_file(CVS/Entries.Log)
> S-> Parse_Info (/home/p4cvs/src/CVSROOT/verifymsg,
> common_install3/c-projects/pw
> check, not ALL)
> S-> unlink_file(/tmp/cvsBfxwCc)
> S-> RCS_checkout
> (/home/p4cvs/src/common_install3/c-projects/pwcheck/pwcheck.cpp
> ,v, 1.8, , -ko, /tmp/cvsnwyJm4)

Right here we expect to see something like this

            --------------- expected output ---------------
new revision: 1.9; previous revision: 1.8
S-> unlink(/tmp/cvsnwyJm4)
S-> unlink(/tmp/cvsBfxwCc)
S-> RCS_checkout 
(/home/p4cvs/src/common_install3/c-projects/pwcheck/pwcheck.cpp,v, , , , 
S-> server_register (pwcheck.cpp, 1.9, www mmm dd hh:mm:ss yyyy, , , , )
S-> Register (pwcheck.cpp, 1.9, www mmm dd hh:mm:ss yyyy, , )
            --------------- expected output ---------------

And of course, we see this:
> Terminated with fatal signal 11


> -> rename(CVS/Entries.Backup,CVS/Entries)
> -> unlink(CVS/Entries.Log)
> any clues.

Well, the server likely has a core file which would be very interesting
to see, but it seems fairly likely that the core dump is happening while
it is attempting to checkout version 1.8 and apply a diff to it.

You have not specified what Operating system you are using, so it is a
lot harder to try to figure out why that operation should have caused a
core dump. Did you notice if /tmp/cvsnwyJm4 was populated at all?

Really, it is probably going to be necessary to look at a core file to
figure out where things went wrong.

        -- Mark
Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

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