Bugzilla Bug 124733

upgraded to 1.12.13 earlier today and since then, my gentoo cvs commits have
been randomly hanging ... then when i kill them and run `cvs up` to see what
needs repairing, i get these weird '.new.<file i was trying to commit>' files
that cvs usually cleans up while running `cvs up` ...

cant seem to narrow it down at all, but i hit this:

$ cvs-1.12.13 -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/bitpim \
  co -P bitpim
....
U bitpim/unixpkg/getallwxlibs
U bitpim/unixpkg/rpathfixup
cvs checkout: inflate: invalid code lengths set
cvs [checkout aborted]: reading from server: Input/output error
$ cd bitpim
$ cvs-1.12.13 up
? winpkg/.new.unicows.d
cvs update: inflate: invalid code lengths set
cvs [update aborted]: reading from server: Input/output error
$ cvs-1.12.12 up
? winpkg/.new.unicows.d
U winpkg/unicows.dll
$ cvs-1.12.12 up
$ rm -r winpkg
$ cvs-1.12.13 up
cvs update: inflate: invalid code lengths set
cvs [update aborted]: reading from server: Input/output error
$ cvs-1.12.13 up
? winpkg/.new.unicows.d
cvs-1.12.13 update: inflate: invalid code lengths set
cvs-1.12.13 [update aborted]: reading from server: Input/output error
$ cvs-1.12.12 up
? winpkg/.new.unicows.d
U winpkg/unicows.dll
$ cvs-1.12.12 up
$

the other thing that i cant really show here is that 1.12.13 tends to sit there
for a while before erroring while 1.12.12 runs through quickly



Portage 2.1_pre5-r2 (default-linux/amd64/2005.1, gcc-4.0.2, glibc-2.3.6-r2,
2.6.14.6-grsec x86_64)
=================================================================
System uname: 2.6.14.6-grsec x86_64 AMD Athlon(tm) 64 Processor 3500+
Gentoo Base System version 1.6.14
distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632)
[disabled]
ccache version 2.4 [enabled]
dev-lang/python:     2.4.2-r1
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.15.92.0.2-r10, 2.16-r1, 2.16.1, 2.16.1-r2, 2.16.90.0.3,
2.16.91.0.1, 2.16.91.0.2, 2.16.91.0.3, 2.16.91.0.4, 2.16.91.0.5, 2.16.91.0.6
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r4
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=k8 -pipe -D_FORTIFY_SOURCE=1
-Wimplicit-function-declaration"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/share/X11/xkb /usr/share/config /var/qmail/alias /var/qmail/control
/var/vpopmail/domains /var/vpopmail/etc"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-O2 -march=k8 -pipe -D_FORTIFY_SOURCE=1"
DISTDIR="/usr/portage/distfiles"
FEATURES="assume-digests autoconfig ccache cvs distlocks noauto noinfo sandbox
sfperms sign splitdebug"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LDFLAGS="-Wl,-O1 -Wl,-z,relro"
LINGUAS="en"
MAKEOPTS="-j6"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://gentoo/gentoo-portage"
USE="amd64 X a52 aac aalib acl adns aio alsa asf audiofile berkdb bitmap-fonts
bzip2 cairo cddb cdparanoia crypt cups dba directfb divx4linux dts dvd dvdr
dvdread emboss encode esd exif fbcon ffmpeg flac flash foomaticdb gd gif glitz
glut gphoto2 gpm gtk gtk2 imap imlib ipv6 jbig joystick jpeg jpeg2k libcaca
libedit lzo lzw lzw-tiff mad maildir matroska mikmod mime mng modplug mp3 mpeg
mplayer multislot ncurses nls nptl nptlonly nvidia offensive ogg oggvorbis
openal opengl pcre pdflib perl pic png python quicktime readline real samba sdl
sndfile spell ssl subtitles svg tcltk tcpd tga theora threads tiff truetype
truetype-fonts type1-fonts usb userlocales vcd vorbis wmf xanim xine xinerama
xml xml2 xmms xpm xrandr xv xvid xvmc zlib elibc_glibc kernel_linux linguas_en
userland_GNU video_cards_nvidia"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL

spanky: is this limited to cvs.sf.net or does it happen with a lot of other cvs
servers as well? eg cvs.g.o?

at the top of my original description:
upgraded to 1.12.13 earlier today and since then, my gentoo cvs commits have
been randomly hanging ...

source of bug seems to be cvs's interaction with zlib. Using the internal zlib
doesn't produce any improvements.

running with -z0 works perfectly fine,
using various other -z* levels produce hangs and errors around the compression
points.

Upstream's cvshome website is down, as are the lists.nongnu.org.

pylon: I'm going to mask cvs-1.12.13 for the moment.

I also had one hang.  But I thought, that the cause was my unsteady
net-connection...

@robbat2: Thanks for masking

PS: cvs.non-gnu.org is just a kind of wrapper-page with some general
information.  The real successor of cvshome is http://ximbiot.com/cvs/

Upstream says, it's fixed...

...in their CVS, so it will be part of 1.12.14 (see bug
http://savannah.nongnu.org/bugs/index.php?func=detailitem&item_id=15087).  As
those bugs where closed already, I didn't saw them before committing a newer
cvs-version into portage.

I am observing the slowdowns for few weeks as well on my ~x86 machine with
1.12.13. Will try 1.12.13r3 now if I get through the upgrade (currently
sys-libs/glibc-2.4-r1 compile breaks for me). Anyway, what I do see here is:

$ cvs -t -z9 commit -m "blah" classes.py
  -> main: Session ID is oUMVrBKUQBzPmdqr
  -> main loop with CVSROOT=/home/xxx/.cvsroot
  -> open_connection_to_server (xxx@x.x.x.x:/home/xxx/.cvsroot)
 -> Starting server: ssh -l xxx x.x.x.x cvs server 
  -> Sending file `classes.py' to server
S -> serve_directory (.)
S -> dirswitch (., /home/xxx/.cvsroot/xxx)

And now the connection stalls. tcpdump tracing shows no traffic between the
machines. I have also seen less problems when using -z0 but it still doesn't
help always.

mmokrejs: did you read this thread before posting? 
1.12.13 is deliberately masked because it's broken, and I don't know where
you're getting 1.12.13r3, that certainly isn't in the tree.
Downgrade to 1.12.12* and you will be fine.

Yes, I have read the thread. But it wasn't clear what exactly was causing the
slowdowns. So that's why I've posted. Yes, "1.12.13r3" was my typo, I've meant
"1.12.12r3".

Yes, 
USE=server" emerge =dev-util/cvs-1.12.12-r3

Created an attachment (id=84319) [details]
cvs-1.12.13-zlib.patch

Ok, I'm testing the zlib patch now, I'll report back soon.

Ok, i've just commited 1.12.13-r1, masked with package.mask.
It passes my testing, but I want you to test it as well, before I remove it
from package.mask.

I've added a functional src_test, but it doesn't test this bug.

Please test this issue, and report back.

a quick test shows it working OK ...

cvs-1.12.13.1 is going into the tree shortly, and contains all of upstream's
recommended fixes for this.
i'll keep it p.mask for a week or two, and then move to ~arch.

ok, xnay on the 1.12.13.1. while it passes all of it's own tests file, it does
some other weird shit when I try to use it with other CVS servers.