From co9@xs4all.nl  Mon Oct 28 05:20:10 2002
Return-Path: <co9@xs4all.nl>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id D32E237B401; Mon, 28 Oct 2002 05:20:10 -0800 (PST)
Received: from a194-109-252-84.adsl.xs4all.nl (a194-109-252-84.adsl.xs4all.nl [194.109.252.84])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 7877943E6E; Mon, 28 Oct 2002 05:20:09 -0800 (PST)
	(envelope-from co9@xs4all.nl)
Received: by a194-109-252-84.adsl.xs4all.nl (Postfix, from userid 1001)
	id E37093A9C; Mon, 28 Oct 2002 14:20:53 +0100 (CET)
Message-Id: <20021028132053.E37093A9C@a194-109-252-84.adsl.xs4all.nl>
Date: Mon, 28 Oct 2002 14:20:53 +0100 (CET)
From: Robin Schilham <co9@xs4all.nl>
Reply-To: Robin Schilham <co9@xs4all.nl>
To: FreeBSD-gnats-submit@freebsd.org
Cc: peter@FreeBSD.ORG
Subject: [PATCH] Aborted cvs session causes an endless loop in cvs server.
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         44564
>Category:       gnu
>Synopsis:       [patch] Aborted cvs session causes an endless loop in cvs server.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    peter
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Oct 28 05:30:01 PST 2002
>Closed-Date:    Wed Sep 14 18:43:16 UTC 2011
>Last-Modified:  Wed Sep 14 18:43:16 UTC 2011
>Originator:     Robin Schilham
>Release:        FreeBSD 4.7-STABLE i386
>Organization:
>Environment:
System: FreeBSD xxx.adsl.xs4all.nl 4.7-STABLE FreeBSD 4.7-STABLE #0: Tue Oct 22 22:00:40 CEST 2002 root@xxx.adsl.xs4all.nl:/usr/obj/usr/src/sys/OMNI i386

>Description:
The command "cvs server" registers two signal handlers for SIGINT. 
As a result, SIGINT (control-C) triggers server_cleanup invocation 
twice. During the second invocation of server_cleanup, the assertion 
"fstat ( fileno (bc->fp), &s ) != -1" (buffer.c, line 1372)
fails because stdin has already been closed during the first invocation
of server_cleanup. Assertion failure causes a SIGABRT, which triggers
server_cleanup again, resulting in an endless loop that can only be
terminated by a SIGTERM.

The same situation occurs when the client interrupts a cvs update or 
cvs checkout, leaving the server in an endless loop, and increasing 
the server load by 1. 

This bug was introduced in 
  Concurrent Versions System (CVS) 1.11.2-FreeBSD (client/server)
and does not exist in 
  Concurrent Versions System (CVS) 1.11.1p1-FreeBSD (client/server)
  
>How-To-Repeat:
There are two ways:
1) execute "cvs server" and press control-C, or
2) do a (preferable large) cvs update or cvs checkout and press control-C
   during the session.

>Fix:
See attached patches (src/contrib/cvs/src):
patch-buffer.c prevents the endless loop.
patch-server.c prevents "cvs in free(): warning: chunk is already free".
>Release-Note:
>Audit-Trail:

From: Robin Schilham <co9@xs4all.nl>
To: freebsd-gnats-submit@FreeBSD.org, co9@xs4all.nl
Cc:  
Subject: Re: gnu/44564: [PATCH] Aborted cvs session causes an endless loop
 in cvs server.
Date: Mon, 28 Oct 2002 15:57:55 +0100

 OK, and the patches are:
 
 --- buffer.c.orig	Mon Oct 28 12:40:16 2002
 +++ buffer.c	Mon Oct 28 12:43:50 2002
 @@ -1462,6 +1462,8 @@
   	&& waitpid (bc->child_pid, (int *) 0, 0) == -1)
   	error (1, errno, "waiting for process %d", bc->child_pid);
 
 +    buf->shutdown = NULL;
 +
       return 0;
   }
 
 --- server.c.orig	Mon Oct 28 12:40:29 2002
 +++ server.c	Mon Oct 28 12:44:10 2002
 @@ -332,6 +332,7 @@
        struct buffer *buf;
   {
       free (buf->closure);
 +    buf->shutdown = NULL;
       return 0;
   }
 
 

From: Oliver Eikemeier <eikemeier@fillmore-labs.com>
To: freebsd-gnats-submit@FreeBSD.org, co9@xs4all.nl
Cc:  
Subject: Re: gnu/44564: [PATCH] Aborted cvs session causes an endless loop
 in cvs server.
Date: Fri, 01 Nov 2002 17:07:18 +0100

 I can confirm this bug, and the patch solved my problems. IMHO this bug 
 should be marked as critical: The hanging server processes used up all 
 available CPU time on our repository.
 

From: Ruslan Ermilov <ru@FreeBSD.org>
To: Peter Wemm <peter@FreeBSD.org>, Robin Schilham <co9@xs4all.nl>
Cc: stable@FreeBSD.org, bug-followup@FreeBSD.org
Subject: gnu/44564 (was: Re: CVS pserver in FreeBSD 4.7-STABLE)
Date: Wed, 6 Nov 2002 11:05:21 +0200

 On Tue, Nov 05, 2002 at 11:26:26PM +0100, Robin Schilham wrote:
 > Ruslan Ermilov wrote:
 > >--9amGYk9869ThD9tj
 > >Content-Type: text/plain; charset=us-ascii
 > >Content-Disposition: inline
 > >Content-Transfer-Encoding: quoted-printable
 > >
 > >On Mon, Oct 28, 2002 at 01:00:52PM -0800, Kris Kennaway wrote:
 > >
 > >>On Mon, Oct 28, 2002 at 05:18:19PM +0500, Eugene M. Zheganin wrote:
 > >>
 > >>>Hi, all.
 > >>>=20
 > >>>Ater installing FreeBSD 4.7-STABLE from cvsup I niticed the follwing
 > >>>problem: there is an CVS-repository on one of my FreeBSD boxes, and
 > >>>during it's work from time to time some cvs procecces appear; they do
 > >>>nothing, but their summary CPU load is enough high:
 > >>>=20
 > >>> PID USERNAME      PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU C=
 > >>
 > >OMMAND
 > >
 > >>>4958 hunter         64   0 67144K   648K RUN      7:34 15.58% 15.58% c=
 > >>
 > >vs
 > >
 > >>>4939 alex           64   0 67144K   568K RUN      7:57 15.28% 15.28% c=
 > >>
 > >vs
 > >
 > >>>4960 hunter         64   0 67144K 10348K RUN      7:34 14.21% 14.21% c=
 > >>
 > >vs
 > >
 > >>>4971 hunter         64   0 67144K 66400K RUN      7:34 14.11% 14.11% c=
 > >>
 > >vs
 > >
 > >>>4919 alex           64   0 67144K   568K RUN      7:44 13.23% 13.23% c=
 > >>
 > >vs
 > >
 > >>=20
 > >>I think this is a known bug in CVS: I'm CC'ing Peter on the reply
 > >>because he'll know more.
 > >>=20
 > >
 > >I'm seeing this two, after upgrading our 4.5-STABLE box to 4.7-STABLE last
 > >Saturday.  For example:
 > >
 > >  PID USERNAME      PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU 
 > >  COMMA=
 > >ND
 > >65743 cvh            55   0 67316K 66768K RUN    220:23 85.84% 85.84% cvs
 > >
 > >
 > >>>There is at list one zombie process among them:
 > >>>=20
 > >>># ps -ax | grep cvs
 > >>>4919  ??  Rs     7:50,15 cvs --allow-root=3D/usr/local/public/cvs pser=
 > >>
 > >ver
 > >
 > >>>4939  ??  Rs     8:02,97 cvs --allow-root=3D/usr/local/public/cvs pser=
 > >>
 > >ver
 > >
 > >>>4958  ??  Rs     7:40,10 cvs --allow-root=3D/usr/local/public/cvs pser=
 > >>
 > >ver
 > >
 > >>>4960  ??  Rs     7:39,88 cvs --allow-root=3D/usr/local/public/cvs pser=
 > >>
 > >ver
 > >
 > >>>4961  ??  Z      0:00,00  (cvs)
 > >>>4971  ??  Rs     7:39,87 cvs --allow-root=3D/usr/local/public/cvs pser=
 > >>
 > >ver
 > >
 > >>>97058  p1  S+     0:00,02 /bin/csh -c ps -ax | grep cvs
 > >>>97205  p1  S+     0:00,00 grep cvs
 > >>>=20
 > >>>and I think the problem is in that zombie.
 > >>>=20
 > >>>I can kill these procecces only by "killall -9 cvs".
 > >>>=20
 > >>>When I type "kill -9 <zombie PID>" can't kill it.
 > >>>=20
 > >>>I use CVS-repository with password auth, all binaries are from the
 > >>>base system; I launch cvs from inetd.conf with string
 > >>>=20
 > >>>cvspserver      stream  tcp     nowait  root    /usr/bin/cvs    cvs --a=
 > >>
 > >llow-root=3D/usr/local/public/cvs pserver
 > >
 > >>>=20
 > >>>may be I should change some of its flags ?
 > >>>=20
 > >>>WBR Eugene.
 > >>
 > >
 > 
 > See http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/44564
 > 
 I see this has already been fixed in the CVS repo:
 
 RCS file: /cvs/ccvs/src/server.c,v
 Working file: server.c
 head: 1.281
 branch:
 locks: strict
 access list:
 keyword substitution: kv
 total revisions: 294;	selected revisions: 1
 description:
 ----------------------------
 revision 1.280
 date: 2002/10/04 19:56:01;  author: scjones;  state: Exp;  lines: +13 -23
 * client.c (get_responses_and_close, connect_to_pserver): Set
 to_server and from_server to NULL after freeing.
 * main.c (main): Clear server_active when finished.  Also neaten
 up the SERVER_SUPPORT ifdef's.
 * server.c (do_cvs_command): Set protocol_inbuf, stderrbuf, and
 stdoutbuf to NULL after freeing.
 (server_cleanup): Free buf_from_net and buf_to_set and set to NULL.
 Also reset error_use_protocol.
 (server): Don't SIG_register server_cleanup.  main_cleanup (which
 is already registered) outputs a fatal error which causes it to
 be called; registering it directly results in it being called twice.
 (cvs_output): Don't try to use buf_to_net or protocol if they're NULL.
 =============================================================================
 
 So, the minimalistic patch (before -p1 is released) would look like this:
 
 %%%
 Index: server.c
 ===================================================================
 RCS file: /home/ncvs/src/contrib/cvs/src/server.c,v
 retrieving revision 1.13.2.3
 diff -u -r1.13.2.3 server.c
 --- server.c	15 Oct 2002 20:24:38 -0000	1.13.2.3
 +++ server.c	6 Nov 2002 08:57:47 -0000
 @@ -5148,25 +5148,6 @@
  	}
      }
  
 -#ifdef SIGABRT
 -    (void) SIG_register (SIGABRT, server_cleanup);
 -#endif
 -#ifdef SIGHUP
 -    (void) SIG_register (SIGHUP, server_cleanup);
 -#endif
 -#ifdef SIGINT
 -    (void) SIG_register (SIGINT, server_cleanup);
 -#endif
 -#ifdef SIGQUIT
 -    (void) SIG_register (SIGQUIT, server_cleanup);
 -#endif
 -#ifdef SIGPIPE
 -    (void) SIG_register (SIGPIPE, server_cleanup);
 -#endif
 -#ifdef SIGTERM
 -    (void) SIG_register (SIGTERM, server_cleanup);
 -#endif
 -
      /* Now initialize our argument vector (for arguments from the client).  */
  
      /* Small for testing.  */
 %%%
 
 main_cleanup() -> error() -> error_exit() -> server_cleanup().
 
 
 Cheers,
 -- 
 Ruslan Ermilov		Sysadmin and DBA,
 ru@sunbay.com		Sunbay Software AG,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.512.251	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age

From: co9@xs4all.nl
To: "Ruslan Ermilov" <ru@FreeBSD.org>
Cc: "Peter Wemm" <peter@FreeBSD.org>,
	"Robin Schilham" <co9@xs4all.nl>, stable@FreeBSD.org,
	bug-followup@FreeBSD.org
Subject: Re: gnu/44564 (was: Re: CVS pserver in FreeBSD 4.7-STABLE)
Date: Wed, 6 Nov 2002 11:59:52 +0100 (CET)

 > On Tue, Nov 05, 2002 at 11:26:26PM +0100, Robin Schilham wrote:
 >> Ruslan Ermilov wrote:
 >> >--9amGYk9869ThD9tj
 >> >Content-Type: text/plain; charset=us-ascii
 >> >Content-Disposition: inline
 >> >Content-Transfer-Encoding: quoted-printable
 >> >
 >> >On Mon, Oct 28, 2002 at 01:00:52PM -0800, Kris Kennaway wrote:
 >> >
 >> >>On Mon, Oct 28, 2002 at 05:18:19PM +0500, Eugene M. Zheganin wrote:
 >> >>
 >> >>>Hi, all.
 >> >>>=20
 >> >>>Ater installing FreeBSD 4.7-STABLE from cvsup I niticed the follwing
 >> >>>problem: there is an CVS-repository on one of my FreeBSD boxes, and
 >> >>>during it's work from time to time some cvs procecces appear; they do
 >> >>>nothing, but their summary CPU load is enough high:
 >> >>>=20
 >> >>> PID USERNAME      PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU
 >> C=
 >> >>
 >> >OMMAND
 >> >
 >> >>>4958 hunter         64   0 67144K   648K RUN      7:34 15.58% 15.58%
 >> c=
 >> >>
 >> >vs
 >> >
 >> >>>4939 alex           64   0 67144K   568K RUN      7:57 15.28% 15.28%
 >> c=
 >> >>
 >> >vs
 >> >
 >> >>>4960 hunter         64   0 67144K 10348K RUN      7:34 14.21% 14.21%
 >> c=
 >> >>
 >> >vs
 >> >
 >> >>>4971 hunter         64   0 67144K 66400K RUN      7:34 14.11% 14.11%
 >> c=
 >> >>
 >> >vs
 >> >
 >> >>>4919 alex           64   0 67144K   568K RUN      7:44 13.23% 13.23%
 >> c=
 >> >>
 >> >vs
 >> >
 >> >>=20
 >> >>I think this is a known bug in CVS: I'm CC'ing Peter on the reply
 >> >>because he'll know more.
 >> >>=20
 >> >
 >> >I'm seeing this two, after upgrading our 4.5-STABLE box to 4.7-STABLE
 >> last
 >> >Saturday.  For example:
 >> >
 >> >  PID USERNAME      PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU
 >> >  COMMA=
 >> >ND
 >> >65743 cvh            55   0 67316K 66768K RUN    220:23 85.84% 85.84%
 >> cvs
 >> >
 >> >
 >> >>>There is at list one zombie process among them:
 >> >>>=20
 >> >>># ps -ax | grep cvs
 >> >>>4919  ??  Rs     7:50,15 cvs --allow-root=3D/usr/local/public/cvs
 >> pser=
 >> >>
 >> >ver
 >> >
 >> >>>4939  ??  Rs     8:02,97 cvs --allow-root=3D/usr/local/public/cvs
 >> pser=
 >> >>
 >> >ver
 >> >
 >> >>>4958  ??  Rs     7:40,10 cvs --allow-root=3D/usr/local/public/cvs
 >> pser=
 >> >>
 >> >ver
 >> >
 >> >>>4960  ??  Rs     7:39,88 cvs --allow-root=3D/usr/local/public/cvs
 >> pser=
 >> >>
 >> >ver
 >> >
 >> >>>4961  ??  Z      0:00,00  (cvs)
 >> >>>4971  ??  Rs     7:39,87 cvs --allow-root=3D/usr/local/public/cvs
 >> pser=
 >> >>
 >> >ver
 >> >
 >> >>>97058  p1  S+     0:00,02 /bin/csh -c ps -ax | grep cvs
 >> >>>97205  p1  S+     0:00,00 grep cvs
 >> >>>=20
 >> >>>and I think the problem is in that zombie.
 >> >>>=20
 >> >>>I can kill these procecces only by "killall -9 cvs".
 >> >>>=20
 >> >>>When I type "kill -9 <zombie PID>" can't kill it.
 >> >>>=20
 >> >>>I use CVS-repository with password auth, all binaries are from the
 >> >>>base system; I launch cvs from inetd.conf with string
 >> >>>=20
 >> >>>cvspserver      stream  tcp     nowait  root    /usr/bin/cvs    cvs
 >> --a=
 >> >>
 >> >llow-root=3D/usr/local/public/cvs pserver
 >> >
 >> >>>=20
 >> >>>may be I should change some of its flags ?
 >> >>>=20
 >> >>>WBR Eugene.
 >> >>
 >> >
 >>
 >> See http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/44564
 >>
 > I see this has already been fixed in the CVS repo:
 >
 > RCS file: /cvs/ccvs/src/server.c,v
 > Working file: server.c
 > head: 1.281
 > branch:
 > locks: strict
 > access list:
 > keyword substitution: kv
 > total revisions: 294;	selected revisions: 1
 > description:
 > ----------------------------
 > revision 1.280
 > date: 2002/10/04 19:56:01;  author: scjones;  state: Exp;  lines: +13 -23
 > * client.c (get_responses_and_close, connect_to_pserver): Set
 > to_server and from_server to NULL after freeing.
 > * main.c (main): Clear server_active when finished.  Also neaten
 > up the SERVER_SUPPORT ifdef's.
 > * server.c (do_cvs_command): Set protocol_inbuf, stderrbuf, and
 > stdoutbuf to NULL after freeing.
 > (server_cleanup): Free buf_from_net and buf_to_set and set to NULL.
 > Also reset error_use_protocol.
 > (server): Don't SIG_register server_cleanup.  main_cleanup (which
 > is already registered) outputs a fatal error which causes it to
 > be called; registering it directly results in it being called twice.
 > (cvs_output): Don't try to use buf_to_net or protocol if they're NULL.
 > =============================================================================
 >
 > So, the minimalistic patch (before -p1 is released) would look like this:
 >
 
 
 Uhm, minimalistic? My two patches changed only two lines of code...
 ;-)
 
 Regards,
 
 Robin Schilham
 
 
 > %%%
 > Index: server.c
 > ===================================================================
 > RCS file: /home/ncvs/src/contrib/cvs/src/server.c,v
 > retrieving revision 1.13.2.3
 > diff -u -r1.13.2.3 server.c
 > --- server.c	15 Oct 2002 20:24:38 -0000	1.13.2.3
 > +++ server.c	6 Nov 2002 08:57:47 -0000
 > @@ -5148,25 +5148,6 @@
 >  	}
 >      }
 >
 > -#ifdef SIGABRT
 > -    (void) SIG_register (SIGABRT, server_cleanup);
 > -#endif
 > -#ifdef SIGHUP
 > -    (void) SIG_register (SIGHUP, server_cleanup);
 > -#endif
 > -#ifdef SIGINT
 > -    (void) SIG_register (SIGINT, server_cleanup);
 > -#endif
 > -#ifdef SIGQUIT
 > -    (void) SIG_register (SIGQUIT, server_cleanup);
 > -#endif
 > -#ifdef SIGPIPE
 > -    (void) SIG_register (SIGPIPE, server_cleanup);
 > -#endif
 > -#ifdef SIGTERM
 > -    (void) SIG_register (SIGTERM, server_cleanup);
 > -#endif
 > -
 >      /* Now initialize our argument vector (for arguments from the
 > client).  */
 >
 >      /* Small for testing.  */
 > %%%
 >
 > main_cleanup() -> error() -> error_exit() -> server_cleanup().
 >
 >
 > Cheers,
 > --
 > Ruslan Ermilov		Sysadmin and DBA,
 > ru@sunbay.com		Sunbay Software AG,
 > ru@FreeBSD.org		FreeBSD committer,
 > +380.652.512.251	Simferopol, Ukraine
 >
 > http://www.FreeBSD.org	The Power To Serve
 > http://www.oracle.com	Enabling The Information Age
 >
 

From: Ruslan Ermilov <ru@FreeBSD.org>
To: co9@xs4all.nl
Cc: Peter Wemm <peter@FreeBSD.org>, stable@FreeBSD.org,
	bug-followup@FreeBSD.org
Subject: Re: gnu/44564 (was: Re: CVS pserver in FreeBSD 4.7-STABLE)
Date: Wed, 6 Nov 2002 13:38:17 +0200

 On Wed, Nov 06, 2002 at 11:59:52AM +0100, co9@xs4all.nl wrote:
 > > On Tue, Nov 05, 2002 at 11:26:26PM +0100, Robin Schilham wrote:
 > >> Ruslan Ermilov wrote:
 > >> >--9amGYk9869ThD9tj
 > >> >Content-Type: text/plain; charset=us-ascii
 > >> >Content-Disposition: inline
 > >> >Content-Transfer-Encoding: quoted-printable
 > >> >
 > >> >On Mon, Oct 28, 2002 at 01:00:52PM -0800, Kris Kennaway wrote:
 > >> >
 > >> >>On Mon, Oct 28, 2002 at 05:18:19PM +0500, Eugene M. Zheganin wrote:
 > >> >>
 > >> >>>Hi, all.
 > >> >>>=20
 > >> >>>Ater installing FreeBSD 4.7-STABLE from cvsup I niticed the follwing
 > >> >>>problem: there is an CVS-repository on one of my FreeBSD boxes, and
 > >> >>>during it's work from time to time some cvs procecces appear; they do
 > >> >>>nothing, but their summary CPU load is enough high:
 > >> >>>=20
 > >> >>> PID USERNAME      PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU
 > >> C=
 > >> >>
 > >> >OMMAND
 > >> >
 > >> >>>4958 hunter         64   0 67144K   648K RUN      7:34 15.58% 15.58%
 > >> c=
 > >> >>
 > >> >vs
 > >> >
 > >> >>>4939 alex           64   0 67144K   568K RUN      7:57 15.28% 15.28%
 > >> c=
 > >> >>
 > >> >vs
 > >> >
 > >> >>>4960 hunter         64   0 67144K 10348K RUN      7:34 14.21% 14.21%
 > >> c=
 > >> >>
 > >> >vs
 > >> >
 > >> >>>4971 hunter         64   0 67144K 66400K RUN      7:34 14.11% 14.11%
 > >> c=
 > >> >>
 > >> >vs
 > >> >
 > >> >>>4919 alex           64   0 67144K   568K RUN      7:44 13.23% 13.23%
 > >> c=
 > >> >>
 > >> >vs
 > >> >
 > >> >>=20
 > >> >>I think this is a known bug in CVS: I'm CC'ing Peter on the reply
 > >> >>because he'll know more.
 > >> >>=20
 > >> >
 > >> >I'm seeing this two, after upgrading our 4.5-STABLE box to 4.7-STABLE
 > >> last
 > >> >Saturday.  For example:
 > >> >
 > >> >  PID USERNAME      PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU
 > >> >  COMMA=
 > >> >ND
 > >> >65743 cvh            55   0 67316K 66768K RUN    220:23 85.84% 85.84%
 > >> cvs
 > >> >
 > >> >
 > >> >>>There is at list one zombie process among them:
 > >> >>>=20
 > >> >>># ps -ax | grep cvs
 > >> >>>4919  ??  Rs     7:50,15 cvs --allow-root=3D/usr/local/public/cvs
 > >> pser=
 > >> >>
 > >> >ver
 > >> >
 > >> >>>4939  ??  Rs     8:02,97 cvs --allow-root=3D/usr/local/public/cvs
 > >> pser=
 > >> >>
 > >> >ver
 > >> >
 > >> >>>4958  ??  Rs     7:40,10 cvs --allow-root=3D/usr/local/public/cvs
 > >> pser=
 > >> >>
 > >> >ver
 > >> >
 > >> >>>4960  ??  Rs     7:39,88 cvs --allow-root=3D/usr/local/public/cvs
 > >> pser=
 > >> >>
 > >> >ver
 > >> >
 > >> >>>4961  ??  Z      0:00,00  (cvs)
 > >> >>>4971  ??  Rs     7:39,87 cvs --allow-root=3D/usr/local/public/cvs
 > >> pser=
 > >> >>
 > >> >ver
 > >> >
 > >> >>>97058  p1  S+     0:00,02 /bin/csh -c ps -ax | grep cvs
 > >> >>>97205  p1  S+     0:00,00 grep cvs
 > >> >>>=20
 > >> >>>and I think the problem is in that zombie.
 > >> >>>=20
 > >> >>>I can kill these procecces only by "killall -9 cvs".
 > >> >>>=20
 > >> >>>When I type "kill -9 <zombie PID>" can't kill it.
 > >> >>>=20
 > >> >>>I use CVS-repository with password auth, all binaries are from the
 > >> >>>base system; I launch cvs from inetd.conf with string
 > >> >>>=20
 > >> >>>cvspserver      stream  tcp     nowait  root    /usr/bin/cvs    cvs
 > >> --a=
 > >> >>
 > >> >llow-root=3D/usr/local/public/cvs pserver
 > >> >
 > >> >>>=20
 > >> >>>may be I should change some of its flags ?
 > >> >>>=20
 > >> >>>WBR Eugene.
 > >> >>
 > >> >
 > >>
 > >> See http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/44564
 > >>
 > > I see this has already been fixed in the CVS repo:
 > >
 > > RCS file: /cvs/ccvs/src/server.c,v
 > > Working file: server.c
 > > head: 1.281
 > > branch:
 > > locks: strict
 > > access list:
 > > keyword substitution: kv
 > > total revisions: 294;	selected revisions: 1
 > > description:
 > > ----------------------------
 > > revision 1.280
 > > date: 2002/10/04 19:56:01;  author: scjones;  state: Exp;  lines: +13 -23
 > > * client.c (get_responses_and_close, connect_to_pserver): Set
 > > to_server and from_server to NULL after freeing.
 > > * main.c (main): Clear server_active when finished.  Also neaten
 > > up the SERVER_SUPPORT ifdef's.
 > > * server.c (do_cvs_command): Set protocol_inbuf, stderrbuf, and
 > > stdoutbuf to NULL after freeing.
 > > (server_cleanup): Free buf_from_net and buf_to_set and set to NULL.
 > > Also reset error_use_protocol.
 > > (server): Don't SIG_register server_cleanup.  main_cleanup (which
 > > is already registered) outputs a fatal error which causes it to
 > > be called; registering it directly results in it being called twice.
 > > (cvs_output): Don't try to use buf_to_net or protocol if they're NULL.
 > > =============================================================================
 > >
 > > So, the minimalistic patch (before -p1 is released) would look like this:
 > >
 > 
 > Uhm, minimalistic? My two patches changed only two lines of code...
 > ;-)
 > 
 Yes, it *is* minimalistic.  -19 is smaller than +2.
 
 
 Cheers,
 -- 
 Ruslan Ermilov		Sysadmin and DBA,
 ru@sunbay.com		Sunbay Software AG,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.512.251	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age
Responsible-Changed-From-To: freebsd-bugs->peter 
Responsible-Changed-By: ru 
Responsible-Changed-When: Thu Nov 7 08:16:00 PST 2002 
Responsible-Changed-Why:  
Over to CVS maintainer. 

Part of the vendor patch I posted only fixes part of the problem, 
there are some cases that it does not fix. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=44564 

From: Ruslan Ermilov <ru@FreeBSD.org>
To: Peter Wemm <peter@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: gnu/44564: [PATCH] Aborted cvs session causes an endless loop in cvs server.
Date: Thu, 7 Nov 2002 18:56:50 +0200

 On Thu, Nov 07, 2002 at 08:18:49AM -0800, Ruslan Ermilov wrote:
 > Synopsis: [PATCH] Aborted cvs session causes an endless loop in cvs server.
 > 
 > Responsible-Changed-From-To: freebsd-bugs->peter
 > Responsible-Changed-By: ru
 > Responsible-Changed-When: Thu Nov 7 08:16:00 PST 2002
 > Responsible-Changed-Why: 
 > Over to CVS maintainer.
 > 
 > Part of the vendor patch I posted only fixes part of the problem,
 > there are some cases that it does not fix.
 > 
 Merging the complete vendor patch from server.c,v 1.280 cures the
 remaining problems I'm seeing when using Windows CVS 1.10 clients:
 
 %%%
 Index: server.c
 ===================================================================
 RCS file: /home/ncvs/src/contrib/cvs/src/server.c,v
 retrieving revision 1.16
 diff -u -p -r1.16 server.c
 --- server.c	2 Sep 2002 05:57:14 -0000	1.16
 +++ server.c	7 Nov 2002 16:53:21 -0000
 @@ -3217,10 +3217,13 @@ E CVS locks may need cleaning up.\n");
  	buf_flush (buf_to_net, 1);
  	buf_shutdown (protocol_inbuf);
  	buf_free (protocol_inbuf);
 +	protocol_inbuf = NULL;
  	buf_shutdown (stderrbuf);
  	buf_free (stderrbuf);
 +	stderrbuf = NULL;
  	buf_shutdown (stdoutbuf);
  	buf_free (stdoutbuf);
 +	stdoutbuf = NULL;
      }
  
      if (errs)
 @@ -4895,9 +4898,9 @@ server_cleanup (sig)
  
  	status = buf_shutdown (buf_from_net);
  	if (status != 0)
 -	{
  	    error (0, status, "shutting down buffer from client");
 -	}
 +	buf_free (buf_from_net);
 +	buf_from_net = NULL;
      }
  
      if (dont_delete_temp)
 @@ -4906,6 +4909,9 @@ server_cleanup (sig)
  	{
  	    (void) buf_flush (buf_to_net, 1);
  	    (void) buf_shutdown (buf_to_net);
 +	    buf_free (buf_to_net);
 +	    buf_to_net = NULL;
 +	    error_use_protocol = 0;
  	}
  	return;
      }
 @@ -5007,6 +5013,9 @@ server_cleanup (sig)
      {
  	(void) buf_flush (buf_to_net, 1);
  	(void) buf_shutdown (buf_to_net);
 +	buf_free (buf_to_net);
 +	buf_to_net = NULL;
 +	error_use_protocol = 0;
      }
  }
  
 @@ -5148,25 +5157,6 @@ error ENOMEM Virtual memory exhausted.\n
  	}
      }
  
 -#ifdef SIGABRT
 -    (void) SIG_register (SIGABRT, server_cleanup);
 -#endif
 -#ifdef SIGHUP
 -    (void) SIG_register (SIGHUP, server_cleanup);
 -#endif
 -#ifdef SIGINT
 -    (void) SIG_register (SIGINT, server_cleanup);
 -#endif
 -#ifdef SIGQUIT
 -    (void) SIG_register (SIGQUIT, server_cleanup);
 -#endif
 -#ifdef SIGPIPE
 -    (void) SIG_register (SIGPIPE, server_cleanup);
 -#endif
 -#ifdef SIGTERM
 -    (void) SIG_register (SIGTERM, server_cleanup);
 -#endif
 -
      /* Now initialize our argument vector (for arguments from the client).  */
  
      /* Small for testing.  */
 @@ -6362,12 +6352,12 @@ cvs_output (str, len)
      if (len == 0)
  	len = strlen (str);
  #ifdef SERVER_SUPPORT
 -    if (error_use_protocol)
 +    if (error_use_protocol && buf_to_net != NULL)
      {
  	buf_output (saved_output, str, len);
  	buf_copy_lines (buf_to_net, saved_output, 'M');
      }
 -    else if (server_active)
 +    else if (server_active && protocol != NULL)
      {
  	buf_output (saved_output, str, len);
  	buf_copy_lines (protocol, saved_output, 'M');
 %%%
 
 
 Cheers,
 -- 
 Ruslan Ermilov		Sysadmin and DBA,
 ru@sunbay.com		Sunbay Software AG,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.512.251	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age

From: Oliver Eikemeier <eikemeier@fillmore-labs.com>
To: freebsd-gnats-submit@FreeBSD.org
Cc: Robin Schilham <co9@xs4all.nl>, Peter Wemm <peter@FreeBSD.org>,
	Ed Santiago <esm@pobox.com>
Subject: Re: gnu/44564: [PATCH] Aborted cvs session causes an endless loop
 in cvs server.
Date: Mon, 11 Nov 2002 15:07:35 +0100

 I get another reproducible hang:
 
 
 #0  0x8091d72 in compress_buffer_flush ()
 #1  0x804d908 in buf_flush ()
 #2  0x8087d66 in server_cleanup ()
 #3  0x809262c in strip_trailing_slashes ()
 #4  0xbfbfffac in ?? ()
 #5  0x8091b02 in compress_buffer_input ()
 #6  0x8091e29 in compress_buffer_shutdown_input ()
 #7  0x804e2dd in buf_shutdown ()
 #8  0x8087d77 in server_cleanup ()
 #9  0x809262c in strip_trailing_slashes ()
 #10 0xbfbfffac in ?? ()
 #11 0x8091b02 in compress_buffer_input ()
 #12 0x8091e29 in compress_buffer_shutdown_input ()
 #13 0x804e2dd in buf_shutdown ()
 #14 0x8087d77 in server_cleanup ()
 #15 0x809262c in strip_trailing_slashes ()
 #16 0xbfbfffac in ?? ()
 ... ad infinitum
 
 The process tries to eat up all available memory & cpu time. Currently 
 we can reproduce it with a FreeBSD server and WinCVS + Cygwin SSH 
 client, when we start a cvs checkout and interrupt the terminal window 
 (Cygwin ssh) with ctrl-C.
 
 It look like:
 CVS server and SIGPIPE hang (1.11.2) 
 <http://mail.gnu.org/pipermail/info-cvs/2002-September/029791.html>
 
 but the patch does not seem to help.
 

From: Oliver Eikemeier <eikemeier@fillmore-labs.com>
To: freebsd-gnats-submit@FreeBSD.org, Robin Schilham <co9@xs4all.nl>
Cc: Peter Wemm <peter@FreeBSD.org>, Ed Santiago <esm@pobox.com>
Subject: Re: gnu/44564: [PATCH] Aborted cvs session causes an endless loop
 in cvs server.
Date: Tue, 12 Nov 2002 14:58:49 +0100

 The cvs server process hang seems to occur only when protocol 
 compression is enabled (i.e. -z3)
 

From: Henrik Nordstrom <hno@squid-cache.org>
To: freebsd-gnats-submit@FreeBSD.org, co9@xs4all.nl
Cc:  
Subject: Re: gnu/44564: [PATCH] Aborted cvs session causes an endless loop in cvs server.
Date: Sat, 14 Dec 2002 14:25:01 +0100

 There is apparently multiple issues in 1.11.2.
 
 a) There is the issue about cvs server getting stuck in an endless 
 loop causing 100% CPU utilization.
 
 b) There is another where the cvs server getting hung in certain 
 situations involving older clients using compression.
 
 
 This is a answer received from Larry Jones in response to a ccvs bug 
 report:
 
 Larry Jones wrote:
 
 There's a known incompatibility between CVS 1.11.2 and previous 
 clients
 when using compression that causes a hung server with no CPU
 utilization.  There's another known bug that causes the server to go
 into an infinite loop when a signal is received under certain
 circumstances.  Both of these problems are fixed in the current
 development version of CVS that you can get from the repository at
 www.cvshome.org.
 
 -Larry Jones
 
 
 
 From what I can tell the patch discussed in this freebsd gnats report 
 is mainly for the second issue where "cvs server" gets stuck in an 
 endless loop using all CPU time. This is also seems to be the main 
 problem we are having at cvs.squid-cache.org after a recent FreeBSD 
 update...
 
 Regards
 Henrik Nordstrm
 Squid HTTP Proxy project
State-Changed-From-To: open->closed 
State-Changed-By: peter 
State-Changed-When: Wed Sep 14 18:41:36 UTC 2011 
State-Changed-Why:  
Sorry, the hacked up freebsd-cvs will likely go away entirely 
before there's server or protocol changes to support this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=44564 
>Unformatted:
