Sun 23 Oct 2005 11:48:18 PM UTC, comment #2:
Further investigation revealed the following -
With cvs 1.12.13 neither external nor bundled zlib 1.2.3 made any difference. In either case the CVS server process is hung in select as it is trying to read more data than what client expects to send as part of the compressed stream.
If you look at the attached trace files, you will see:
1) The ethereal capture shows client sending 8311 bytes to server. The exact same bytes stream from client to a cvs 1.12.12 server (with external zlib 1.2.3) encounters no problem whatsoever, as the server is able to decompress fine. With a cvs 1.12.13 server, the server is trying to read 1 byte, beyond 8311.
====
smp2 /tmp/cvs-serv24028# grep "read(0" /tmp/trace
read(0, "BEGIN AUTH REQUEST\n/tmp/cvsroot\n"..., 4096) = 65
read(0, "Root /tmp/cvsroot\nValid-response"..., 4096) = 396
read(0, "UseUnchanged\nGzip-stream 6\nx\234r\316\317"..., 3700) = 55
read(0, "\304\\{s\333\306\265\377\233\374\24ktl\221\22IIN\322$R"..., 4096) = 4096
read(0, "\356=c\266\23\2118L;\262\332,\"\247\224\226\34\376\323"..., 4096) = 3699
smp2 /tmp/cvs-serv24028# bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
65+396+55+4096+3699
8311
======
If you grep through the strace file, you can see the server's byte accouting is off causing it to get stuck in select. In short the bug seems to be with reading compressed stream off the STDIN not a zlib issue. Please reopen the bug so that we can track it.
Regards,
Rahul Bhargava
|