Re: Lock files in version 1.11.11

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Zanabria, Moises <address@hidden> 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: address@hidden [mailto:address@hidden
> Sent: Wednesday, January 14, 2004 4:35 PM
> To: Zanabria, Moises
> Cc: address@hidden; Zanabria, Moises; address@hidden
> 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" <address@hidden>
> To: "Zanabria, Moises" <address@hidden>
> Cc: "'address@hidden'" <address@hidden>
> 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 <address@hidden> 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"  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()
> 
> 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: 'address@hidden'
> > 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: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 
> > 
> > 
> > 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)

iD8DBQFAW1xh3x41pRYZE/gRApaUAJ9b3kFyS7VfWyegFpefInkYmqGzUwCglrZ8
jFMeT4LAMzOTOsDvR/z86M8=
=KKAd
-----END PGP SIGNATURE-----