Date: Mon, 16 Sep 2002 21:37:21 -0700 From: Alfred Perlstein <bright@mu.org> To: hackers@freebsd.org Cc: des@freebsd.org, kris@freebsd.org Subject: libfetch bug. Message-ID: <20020917043721.GG86737@elvis.mu.org>
next in thread | raw e-mail | index | archive | help
libfetch seems to have a bug such that if a disconnect happens at
a particular point it spins in a tight loop.
I tracked it down to this fix:
Index: common.c
===================================================================
RCS file: /home/ncvs/src/lib/libfetch/common.c,v
retrieving revision 1.31
diff -u -r1.31 common.c
--- common.c 24 Jun 2002 12:18:41 -0000 1.31
+++ common.c 17 Sep 2002 04:28:12 -0000
@@ -404,6 +404,7 @@
char *tmp;
size_t tmpsize;
char c;
+ int error;
if (conn->buf == NULL) {
if ((conn->buf = malloc(MIN_BUF_SIZE)) == NULL) {
@@ -417,8 +418,11 @@
conn->buflen = 0;
do {
- if (_fetch_read(conn, &c, 1) == -1)
+ error = _fetch_read(conn, &c, 1);
+ if (error == -1)
return (-1);
+ else if (error == 0)
+ break;
conn->buf[conn->buflen++] = c;
if (conn->buflen == conn->bufsize) {
tmp = conn->buf;
The problem is that _fetch_read will return 0 if the connection is
broken and the code doesn't check for that. Can someone please
review it?
A good way to test this is to try to "make fetch" the shells/bash2
port which will cause the hang, one can then "kill -QUIT" the fetch
process to get a traceback.
Thanks to Kris for pointing out that it was actually a bug in our
client software (i mistakenly thought the ftp site was just flakey
:)).
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020917043721.GG86737>