-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Zanabria, Moises <[EMAIL PROTECTED]> writes:
> I'm wondering if SETXID_SUPPORT has been tested since 1.11.11 has been > released. > Thank you all. > Moises. If you have tests to provide for us, that would be great, but I have not tested it myself. -- Mark > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 14, 2004 4:35 PM > To: Zanabria, Moises > Cc: [EMAIL PROTECTED]; Zanabria, Moises; [EMAIL PROTECTED] > Subject: Re: Lock files in version 1.11.11 > > > Zanabria, Moises writes: > > > > I built 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. > > As far as I know, no one ever tests SETXID_SUPPORT. I wonder if that's > the root of the problem? > > -Larry Jones > > From now on, I'm devoting myself to the cultivation of > interpersonal relationships. -- Calvin > > > ------- Forwarded Message > > From: "Mark D. Baushke" <[EMAIL PROTECTED]> > To: "Zanabria, Moises" <[EMAIL PROTECTED]> > Cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Subject: Re: Lock files in version 1.11.11 > Date: Wed, 14 Jan 2004 15:25:30 -0600 > X-Mailer: Internet Mail Service (5.5.2653.19) > > Zanabria, Moises <[EMAIL PROTECTED]> writes: > > > BTW. > > when I upgraded the version I just replaced the binary didn't run "make > > install" > > Just upgrading the version of the cvs executable should be fine. > > > I've just searched in all system and there is not a core file.. > > Hmmm... that makes it harder. > > I will note that I am not sure that much testing has been done to the > SETXID_SUPPORT feature. It is disabled by default and is not normally > tested. > > > > > > 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" [EMAIL PROTECTED],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() > > The above partial trace shows cvs running the loginfo trigger. > This second trace has insufficient context to tell me what you > were doing. > > > > > 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. > > -- Mark > > > > > > > -----Original Message----- > > From: Zanabria, Moises > > Sent: Wednesday, January 14, 2004 10:01 AM > > To: 'Mark D. Baushke'; Zanabria, Moises > > Cc: '[EMAIL PROTECTED]' > > Subject: RE: Lock files in version 1.11.11 > > > > > > I built 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:[EMAIL PROTECTED] > > Sent: Wednesday, January 14, 2004 1:51 AM > > To: Zanabria, Moises > > Cc: '[EMAIL PROTECTED]' > > Subject: Re: Lock files in version 1.11.11 > > > > > > Zanabria, Moises <[EMAIL PROTECTED]> 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) iD8DBQFAW1xh3x41pRYZE/gRApaUAJ9b3kFyS7VfWyegFpefInkYmqGzUwCglrZ8 jFMeT4LAMzOTOsDvR/z86M8= =KKAd -----END PGP SIGNATURE----- _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs