Re: cvsup servers broken?

Matt wrote:
> On 07/01/11 09:34, Ian FREISLICH wrote:
> > It looks like the server is just exiting.  I've tested cvsup4 and
> > cvsup5 as well.  Is cvsup deprecated these days or has something
> > else broken it?
> >
> Try csup instead of cvsup...I've found it works better. Any possibility 
> of network issues?

csup gets into an infinite loop near the end of the ports tree and
starts growing in memory consumption.  I killed it after it grew
to about 500M resident.  The following is a ktrace snippet after
it stalls:

 75390 csup     RET   ioctl -1 errno 25 Inappropriate ioctl for device
 75390 csup     CALL  ioctl(0x4,TIOCGETA,0xbf5fac60)
 75390 csup     RET   ioctl -1 errno 25 Inappropriate ioctl for device
 75390 csup     CALL  ioctl(0x4,TIOCGETA,0xbf5fac60)
 75390 csup     RET   ioctl -1 errno 25 Inappropriate ioctl for device
 75390 csup     CALL  ioctl(0x4,TIOCGETA,0xbf5fac60)
 75390 csup     RET   ioctl -1 errno 25 Inappropriate ioctl for device
 75390 csup     CALL  ioctl(0x4,TIOCGETA,0xbf5fac60)
 75390 csup     RET   ioctl -1 errno 25 Inappropriate ioctl for device
 75390 csup     CALL  ioctl(0x4,TIOCGETA,0xbf5fac60)

The first part of csup's stack trace.  It appears to be corrupted
with several null frames, and is very, very deep.

(gdb) bt
#0  0x2832c1f3 in ioctl () from /lib/libc.so.7
#1  0x2832bdbc in tcgetattr () from /lib/libc.so.7
#2  0x2832b7ea in isatty () from /lib/libc.so.7
#3  0x08051832 in fnmatch ()
#4  0x08051906 in fnmatch ()
#5  0x08052135 in fnmatch ()
#6  0x08059c19 in fnmatch ()
#7  0x08059a76 in fnmatch ()
#8  0x0804c1ff in ?? ()
#9  0x28c11380 in ?? ()
#10 0x2845f402 in ?? ()

[mini] /usr/home/ianf # procstat -f  75390
  PID COMM               FD T V FLAGS    REF  OFFSET PRO NAME        
75390 csup             text v r r-------   -       - -   /usr/bin/csup     
75390 csup             ctty v c rw------   -       - -   /dev/pts/1        
75390 csup              cwd v d r-------   -       - -   /usr/src          
75390 csup             root v d r-------   -       - -   /                 
75390 csup                0 v c rw------  14 10464115 -   /dev/pts/1        
75390 csup                1 v c rw------  14 10464115 -   /dev/pts/1        
75390 csup                2 v c rw------  14 10464115 -   /dev/pts/1        
75390 csup                3 s - rw------   2       0 TCP 10.0.2.67:19238 128.205.32.24:5999
75390 csup                4 v r r-------   1       0 -   /usr/home/ncvs/ports/x11/wbar/Makefile,v
75390 csup                5 v r r-------   1    1023 -   /var/db/sup/ports-all/checkouts
75390 csup                6 v r r-------   1 24492073 -   /var/db/sup/ports-all/checkouts
75390 csup                7 v r -w------   1 24491389 -   /var/db/sup/ports-all/#cvs.csup-75390.0

filedescriptor 4's directory listing:

[mini] /usr/home/ncvs/ports/x11/wbar # ls -la
total 24
drwxr-xr-x    3 root  wheel    512 Jul  1 07:21 .
drwxr-xr-x  694 root  wheel  14848 Jun 28 16:29 ..
-r--r--r--    1 root  wheel      0 Feb  8 22:51 Makefile,v
-r--r--r--    1 root  wheel      0 Mar 19 14:38 distinfo,v
drwxr-xr-x    2 root  wheel    512 Jul  1 07:21 files
-r--r--r--    1 root  wheel      0 Feb  8 22:51 pkg-descr,v
-r--r--r--    1 root  wheel      0 Feb  8 22:51 pkg-plist,v

After removing the zero sized files, csup continued until it hit
x11-toolkits/Makefile,v and then ports/x11-wm/Makefile,v which was
also zero sized.  Having deleted all the zero files, both cvsup and
csup complete their run.

So, why does it fail so absurdly on this condition?

Ian

-- 
Ian Freislich