Re: cvsup servers broken?

On Sat, 2 Jul 2011, Ian FREISLICH wrote:
> 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.

I don't think you'll get much interest in fixing cvsup, but if you can 
recreate this at will with csup and haven't had a response in a few days, 
could you please submit a PR?

Thanks,

Gavin