From owner-freebsd-hackers Mon Sep 16 21:37:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAD2C37B400; Mon, 16 Sep 2002 21:37:21 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89F3343E77; Mon, 16 Sep 2002 21:37:21 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 5A0F4AE1C1; Mon, 16 Sep 2002 21:37:21 -0700 (PDT) Date: Mon, 16 Sep 2002 21:37:21 -0700 From: Alfred Perlstein To: hackers@freebsd.org Cc: des@freebsd.org, kris@freebsd.org Subject: libfetch bug. Message-ID: <20020917043721.GG86737@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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