From nobody@FreeBSD.org  Thu Oct 27 16:16:29 2011
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id DF25E106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 27 Oct 2011 16:16:28 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id C4D3D8FC1A
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 27 Oct 2011 16:16:28 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p9RGGS6B061424
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 27 Oct 2011 16:16:28 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id p9RGGS61061423;
	Thu, 27 Oct 2011 16:16:28 GMT
	(envelope-from nobody)
Message-Id: <201110271616.p9RGGS61061423@red.freebsd.org>
Date: Thu, 27 Oct 2011 16:16:28 GMT
From: Fabian Keil <fk@fabiankeil.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Loop in fetch when sending SIGINFO after the server stopped sending data
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         162064
>Category:       bin
>Synopsis:       [patch] Loop in fetch(1) when sending SIGINFO after the server stopped sending data
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Oct 27 16:20:07 UTC 2011
>Closed-Date:    Mon Mar 12 19:29:31 UTC 2012
>Last-Modified:  Mon Mar 12 19:29:31 UTC 2012
>Originator:     Fabian Keil
>Release:        HEAD
>Organization:
>Environment:
FreeBSD r500.local 10.0-CURRENT FreeBSD 10.0-CURRENT #370 r+e5cde8a: Tue Oct 25 21:12:37 CEST 2011     fk@r500.local:/usr/obj/usr/src/sys/ZOEY  amd64

>Description:
If fetch receives SIGINFO after the server stopped sending
data it goes into a loop and starts eating 100% cpu even
continuing after the connection to the server has been
closed.

It's my impression that fetch.c relies on fread() to modify
errno in a way it doesn't. The following patch prevents the
cpu-eating loop, but fetch still fails to properly save the
received data:

commit 2131ebe654b5d9b48a715ea1955941b9d3e89f4d
Author: Fabian Keil <fk@fabiankeil.de>
Date:   Sat Oct 15 22:12:54 2011 +0200

    Manually set errno to 0 before calling fread() in fetch().

    The fact that this makes a difference seems to suggest
    that fread() doesn't behave like fetch expects it to.

diff --git a/usr.bin/fetch/fetch.c b/usr.bin/fetch/fetch.c
index 9862276..18c6d5a 100644
--- a/usr.bin/fetch/fetch.c
+++ b/usr.bin/fetch/fetch.c
@@ -636,6 +636,7 @@ fetch(char *URL, const char *path)
                        stat_end(&xs);
                        siginfo = 0;
                }
+               errno = 0; /* XXX: Why does this have an effect? */
                if ((size = fread(buf, 1, size, f)) == 0) {
                        if (ferror(f) && errno == EINTR && !sigint)
                                clearerr(f);

>How-To-Repeat:
Run a "webserver" like this one:

(printf "HTTP/1.1 200 Okay\r\nConnection: close\r\nContent-Length: 10\r\n\r\n0123456789"; sleep 5) | nc -l 81

Use fetch to request a resource, send SIGINFO before the sleep
time is up and watch it eating cpu time without doing anything
useful:

fk@r500 ~ $fetch http://127.0.0.1:81/
fetch.out                                       0% of   10  B    0  Bps
load: 0.80  cmd: fetch 3698 [select] 0.70r 0.00u 0.00s 0% 2464k
fetch.out                                       0% of   10  B    0  Bps
fetch.out                                       0% of   10  B    0  Bps
load: 0.83  cmd: fetch 3698 [runnable] 12.32r 0.64u 10.96s 70% 2504k
fetch.out                                       0% of   10  B    0  Bps
fetch.out                                       0% of   10  B    0  Bps
load: 0.87  cmd: fetch 3698 [running] 24.50r 1.22u 22.54s 96% 2504k
fetch.out                                       0% of   10  B    0  Bps
fetch.out                                       0% of   10  B    0  Bps
load: 0.91  cmd: fetch 3698 [running] 52.70r 2.84u 49.10s 100% 2504k
fetch.out                                       0% of   10  B    0  Bps
fetch.out                                       0% of   10  B    0  Bps
load: 0.92  cmd: fetch 3698 [running] 59.60r 3.26u 55.55s 100% 2504k
fetch.out                                       0% of   10  B    0  Bps
fetch.out                                       0% of   10  B    0  Bps^C
fetch: transfer interrupted

With the errno patch one gets:

fk@r500 /tank/scratch $fetch http://127.0.0.1:81/
fetch.out                                       0% of   10  B    0  Bps
load: 0.74  cmd: fetch 3812 [select] 0.69r 0.00u 0.00s 0% 2464k
fetch.out                                       0% of   10  B    0  Bps
fetch.out                                       0% of   10  B    0  Bps
fetch: http://127.0.0.1:81/: No error: 0

and no output file even though all the data has been delivered.

If SIGINFO isn't sent, the resource is properly received.
>Fix:


>Release-Note:
>Audit-Trail:

From: Mark Johnston <markjdb@gmail.com>
To: bug-followup@FreeBSD.org, fk@fabiankeil.de
Cc:  
Subject: Re: bin/162064: [patch] Loop in fetch(1) when sending SIGINFO after
 the server stopped sending data
Date: Sun, 11 Mar 2012 22:52:33 -0400

 This is very similar to/exactly the problem I fixed in libfetch a
 little while ago. Indeed, I can't reproduce it on my laptop running
 CURRENT. See r230307 and bin/153240.
 
 -Mark

From: Fabian Keil <fk@fabiankeil.de>
To: Mark Johnston <markjdb@gmail.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/162064: [patch] Loop in fetch(1) when sending SIGINFO after
 the server stopped sending data
Date: Mon, 12 Mar 2012 18:27:08 +0100

 --Sig_/qh0FNp./aksmLrhtGYLnbKM
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 
 Mark Johnston <markjdb@gmail.com> wrote:
 
 > This is very similar to/exactly the problem I fixed in libfetch a
 > little while ago. Indeed, I can't reproduce it on my laptop running
 > CURRENT. See r230307 and bin/153240.
 
 I noticed r230307 and while I assumed that it might fix it,
 I didn't get around to testing it yet.
 
 Thanks for the reminder (and the fix of course).
 
 I can confirm that the problem is no longer reproducible.
 As far a I'm concerned the PR can be closed.
 
 Fabian
 
 --Sig_/qh0FNp./aksmLrhtGYLnbKM
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Disposition: attachment; filename=signature.asc
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.18 (FreeBSD)
 
 iEYEARECAAYFAk9eMfQACgkQSMVSH78upWMK8gCfcy13J9TjGVxdlFbvpl0qxoEs
 yMoAnRA7iYVPC8eSkHi6D9BRpz7jigog
 =U8tf
 -----END PGP SIGNATURE-----
 
 --Sig_/qh0FNp./aksmLrhtGYLnbKM--
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Mon Mar 12 19:29:20 UTC 2012 
State-Changed-Why:  
Apparently this has already been fixed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=162064 
>Unformatted:
