[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Lock files in version 1.11.11
From: |
Zanabria, Moises |
Subject: |
RE: Lock files in version 1.11.11 |
Date: |
Wed, 14 Jan 2004 15:12:57 -0600 |
BTW.
when I upgraded the version I just replaced the binary didn't run "make
install"
I've just searched in all system and there is not a core file..
also I just realized that this problem almost always occurs in the same code
spot there is another trace:
first time succeed:
S-> RCS_checkout
(/home/p4cvs/src/ntsnapin/Security/SecurityAbout/bldnum.h,v, , , ,
(function))
S-> server_register(bldnum.h, 1.579, Tue Jan 13 07:00:19 2004, , , , )
S-> Register(bldnum.h, 1.579, Tue Jan 13 07:00:19 2004, , )
S-> fopen(/home/p4cvs/src/CVSROOT/history,a)
-> rename(CVS/Entries.Backup,CVS/Entries)
-> unlink(CVS/Entries.Log)
-> unlink(CVS/Base/bldnum.h)
-> Register(bldnum.h, 1.579, Tue Jan 13 07:00:19 2004, , )
S-> Parse_Info (/home/p4cvs/src/CVSROOT/loginfo,
ntsnapin/Security/SecurityAbout, ALL)
S-> run_popen((echo User `id -n -u` updated NT Snapin directory; echo
"ntsnapin/Security/SecurityAbout bldnum.h,1.578,1.579";
cat) | mail -s "CVS Update Report: NT Snapin Update" address@hidden,w)
S-> run_popen((/home/p4cvs/src/CVSROOT/dolog.pl -d /home/p4cvs/src ) >>
/opt/www/cgi-bin/bonsai/P3/data/P3_TEMP/temp.bonsai 2
>&1,w)
S-> run_popen((/opt/www/cgi-bin/bonsai/P3/data/P3_TEMP/mov_bonsai_temp.sh)
>> /dev/null 2>&1,w)
S-> rename(CVS/Entries.Backup,CVS/Entries)
S-> unlink_file(CVS/Entries.Log)
S-> Lock_Cleanup()
-> rename(CVS/Entries.Backup,CVS/Entries)
-> unlink(CVS/Entries.Log)
-> Lock_Cleanup()
second time:
S-> RCS_checkout
(/home/p4cvs/src/ntsnapin/Security/SecurityAbout/bldnum.h,v, 1.579, , -ko,
/tmp/cvs7dtkGg)
Terminated with fatal signal 11
-> rename(CVS/Entries.Backup,CVS/Entries)
-> unlink(CVS/Entries.Log)
-> Lock_Cleanup()
Thanks.
Moises.
-----Original Message-----
From: Zanabria, Moises
Sent: Wednesday, January 14, 2004 10:01 AM
To: 'Mark D. Baushke'; Zanabria, Moises
Cc: 'address@hidden'
Subject: RE: Lock files in version 1.11.11
I build the binary in Linux 2.4.18 using gcc version 2.96 20000731 (Red Hat
Linux 7.1 2.96-98) and also I compiled the source using SETXID_SUPPORT.
top/Makefile
CC = gcc -DSETXID_SUPPORT
top/src/Makefile
CC = gcc -DSETXID_SUPPORT
-rwxr-sr-x 1 root cvsg 1566913 Jan 13 19:30 /usr/local/bin/cvs
>>> Did you notice if /tmp/cvsnwyJm4 was populated at all?
not at all, I've the file.
Thanks.
Moises.
-----Original Message-----
From: Mark D. Baushke [mailto:address@hidden
Sent: Wednesday, January 14, 2004 1:51 AM
To: Zanabria, Moises
Cc: 'address@hidden'
Subject: Re: Lock files in version 1.11.11
-----BEGIN PGP SIGNED MESSAGE-----
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/logcheck.pl' '/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->
rename(/home/p4cvs/src/common_install3/c-projects/pwcheck/,pwcheck.cpp,,/hom
e/p4cvs/src/common_install3/c-projects/pwcheck/pwcheck.cpp,v)
done
S-> unlink(/tmp/cvsnwyJm4)
S-> unlink(/tmp/cvsBfxwCc)
S-> RCS_checkout
(/home/p4cvs/src/common_install3/c-projects/pwcheck/pwcheck.cpp,v, , , ,
(function))
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
instead.
> -> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFABPTJ3x41pRYZE/gRAndIAJ95qFUB+wHRyPhsFWFvFE5ZH2X/xQCaA7cJ
XMqGX8bVuqhc46RN+vcv1aU=
=wkch
-----END PGP SIGNATURE-----
- Lock files in version 1.11.11, Zanabria, Moises, 2004/01/13
- RE: Lock files in version 1.11.11, Zanabria, Moises, 2004/01/14
- RE: Lock files in version 1.11.11,
Zanabria, Moises <=
- RE: Lock files in version 1.11.11, Zanabria, Moises, 2004/01/14
- RE: Lock files in version 1.11.11, Zanabria, Moises, 2004/01/14
- RE: Lock files in version 1.11.11, Zanabria, Moises, 2004/01/15