Date: Sun, 03 Jul 2011 09:42:55 +0200 From: Ian FREISLICH <ianf@clue.co.za> To: Gavin Atkinson <gavin@FreeBSD.org> Cc: Matt <sendtomatt@gmail.com>, current@freebsd.org Subject: Re: cvsup servers broken? Message-ID: <E1QdHKR-000Kkb-Hj@clue.co.za> In-Reply-To: <alpine.LNX.2.00.1107030034440.13721@ury.york.ac.uk.> References: <alpine.LNX.2.00.1107030034440.13721@ury.york.ac.uk.> <4E0E1D59.3030003@gmail.com> <E1Qcgff-0000dX-MN@clue.co.za> <E1QcvSg-000JfG-Ho@clue.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Gavin Atkinson wrote: > 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 12 8.205.32.24:5999 > > 75390 csup 4 v r r------- 1 0 - /usr/home/ncvs/por ts/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? This debugging above was with csup. cvsup would cause the remote to exit (hence the RST). csup would just consume all RAM and CPU when it encounters an empty ,v file. Ian -- Ian Freislich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1QdHKR-000Kkb-Hj>