[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS 1.12.13 hangs when getting gnulib
From: |
Mark D. Baushke |
Subject: |
Re: CVS 1.12.13 hangs when getting gnulib |
Date: |
Sun, 17 Sep 2006 01:00:01 -0700 |
Hi Paul,
It seems it was pilot error on my part when I was
unable to reproduce your problem. The cvs 1.12.13
I was using for the test was actually an
unreleased version of cvs (1.12.13.1 top-of-tree
FEATURE). Sorry about the confusion.
I was able to reproduce the problem when I used a
stock unmodified cvs 1.12.13.
Your problem is the same problem as was reported
in [bug #14840]. I include a copy of the patch as
applied to the CVS FEATURE branch sources after my
.signature.
This patch will be a part of cvs 1.12.14 when it
is eventually released.
In the mean time, feel free to forward this patch
to your upstream distribution provider for their
use.
Enjoy!
-- Mark
ChangeLog entry:
2005-10-28 Derek Price <derek@ximbiot.com>
[bug #14840]
* zlib.c (compress_bufer_input): Don't assume the number of bytes the
caller requested will be available from the stream underlying the
compression buffer - the data is compressed and should be shorter by
definition. Improve comment.
(Original report from Rahul Bhargava <rahul@wandisco.com>.)
Index: src/zlib.c
===================================================================
RCS file: /cvsroot/cvs/ccvs/src/zlib.c,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -p -r1.31 -r1.32
--- src/zlib.c 3 Jun 2005 18:26:09 -0000 1.31
+++ src/zlib.c 28 Oct 2005 14:10:59 -0000 1.32
@@ -221,15 +221,14 @@ compress_buffer_input (void *closure, ch
point. */
assert (bd->size == 0);
- /* This will work well in the server, because this call will
- do an unblocked read and fetch all the available data. In
- the client, this will read a single byte from the stdio
- stream, which will cause us to call inflate once per byte.
- It would be more efficient if we could make a call which
- would fetch all the available bytes, and at least one byte. */
-
+ /* On the server, this will do an unblocking read of as much data as is
+ * available. On the client, with a blocking input descriptor and the
+ * current fd_buffer implementation, this should read as much data as
+ * is currently available, and at least 1 byte (or EOF), from the
+ * underlying buffer.
+ */
status = (*cb->buf->input) (cb->buf->closure, bd->text,
- need, BUFFER_DATA_SIZE, &nread);
+ need ? 1 : 0, BUFFER_DATA_SIZE, &nread);
if (status == -2)
/* Don't try to recover from memory allcoation errors. */