From michiel@boland.org  Mon Oct 11 07:21:45 2004
Return-Path: <michiel@boland.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 2330116A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 11 Oct 2004 07:21:45 +0000 (GMT)
Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 17EC043D3F
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 11 Oct 2004 07:21:44 +0000 (GMT)
	(envelope-from michiel@boland.org)
Received: from xs6.xs4all.nl (xs6.xs4all.nl [194.109.21.6])
	by smtp-vbr9.xs4all.nl (8.12.11/8.12.11) with ESMTP id i9B7LgYC011115
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 11 Oct 2004 09:21:43 +0200 (CEST)
	(envelope-from michiel@boland.org)
Received: from xs6.xs4all.nl (boland37@localhost.xs4all.nl [127.0.0.1])
	by xs6.xs4all.nl (8.12.10/8.12.10) with ESMTP id i9B7LgXC079119
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 11 Oct 2004 09:21:42 +0200 (CEST)
	(envelope-from michiel@boland.org)
Received: (from boland37@localhost)
	by xs6.xs4all.nl (8.12.10/8.12.9/Submit) id i9B7LgWj079118
	for FreeBSD-gnats-submit@freebsd.org; Mon, 11 Oct 2004 09:21:42 +0200 (CEST)
	(envelope-from michiel@boland.org)
Message-Id: <200410110721.i9B7LgWj079118@xs6.xs4all.nl>
Date: Mon, 11 Oct 2004 09:21:42 +0200 (CEST)
From: Michiel Boland <michiel@boland.org>
To: FreeBSD-gnats-submit@freebsd.org
Subject: script(1) loops after EOF is read
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         72501
>Category:       bin
>Synopsis:       script(1) loops after EOF is read
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    cperciva
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Oct 11 07:30:27 GMT 2004
>Closed-Date:    Thu Oct 06 18:06:45 UTC 2011
>Last-Modified:  Thu Oct 06 18:06:45 UTC 2011
>Originator:     Michiel Boland
>Release:        FreeBSD 6.0-CURRENT i386
>Organization:
>Environment:
System: FreeBSD leefnet.office.internl.net 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Sat Oct 9 15:53:21 CEST 2004 root@leefnet.office.internl.net:/usr/obj/usr/src/sys/LEEFNET i386


	
>Description:
The script(1) program loops and consumes all CPU after it reads EOF from
standard input.
>How-To-Repeat:
Start an xterm.
In the xterm, become another user (actually, 'su - $USER' is sufficient)
Type 'script'.
Delete the xterm window.
>Fix:
Quick fix: back out rev 1.24 of src/usr.bin/script/script.c.
Better: find out why writing zero-length bytes to a pty controller does not
generate EOF on the pty slave. (This is what the commit message for 1.24
of script.c claims will happen.)

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->cperciva 
Responsible-Changed-By: cperciva 
Responsible-Changed-When: Mon Oct 11 11:45:47 GMT 2004 
Responsible-Changed-Why:  
I'll take this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=72501 

From: Colin Percival <colin.percival@wadham.ox.ac.uk>
To: freebsd-gnats-submit@freebsd.org, michiel@boland.org
Cc:  
Subject: Re: bin/72501: script(1) loops after EOF is read
Date: Thu, 14 Oct 2004 18:23:33 +0100

 Michiel,
    I'm having trouble reproducing this; after trying on both
 5.2.1-RELEASE and today's 6-CURRENT I can't manage to get
 anything to go wrong.
    Can you tell me anything more which might help me in trying
 to reproduce this?  Or, can you still invoke this bug on a
 more recent (eg, today's) -CURRENT system?
 
 Colin Percival
 cperciva@freebsd.org
 

From: Michiel Boland <michiel@boland.org>
To: Colin Percival <colin.percival@wadham.ox.ac.uk>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/72501: script(1) loops after EOF is read
Date: Fri, 15 Oct 2004 13:59:14 +0200

 On Thu, Oct 14, 2004 at 06:23:33PM +0100, Colin Percival wrote:
 > Michiel,
 >   I'm having trouble reproducing this; after trying on both
 > 5.2.1-RELEASE and today's 6-CURRENT I can't manage to get
 > anything to go wrong.
 >   Can you tell me anything more which might help me in trying
 > to reproduce this?  Or, can you still invoke this bug on a
 > more recent (eg, today's) -CURRENT system?
 
 Today's -CURRENT shows the same behaviour.
 
 Another way to trigger this, which does not involve xterms:
 
 - log in on two terminals, say, ttyv0 and ttyv1
 
 - on ttyv0 type:
 
   script 1
   su - $USER
   script 2
 
 On ttyv1, kill the 'script 1' process. The 'script 2' process will
 then enter a tight loop.
 
 What I think happens is this: we have the following tree of processes
 
  - login shell on ttyv0
    - script 1 (pty0 master)
      - shell on pty0 slave
        - su (setuid root process)
          - shell
            - script 2 (pty1 master) <- foreground process on pty0 slave
              - shell on pty1 slave
 
 Normally, when a pty master is closed, the foreground process group on
 the corresponding slave is sent a HUP signal. (I guess.) But in this case,
 that signal is suppressed, because of the setuid 'su' process in the middle.
 
 FWIW - ktrace on the runaway script shows:-
 
   5841 script   CALL  gettimeofday(0xbfbfe3f8,0)
   5841 script   RET   gettimeofday 0
   5841 script   CALL  select(0x5,0xbfbfe46c,0,0,0xbfbfe454)
   5841 script   RET   select 1
   5841 script   CALL  read(0,0xbfbfe4ec,0x400)
   5841 script   RET   read 0
   5841 script   CALL  write(0x4,0xbfbfe4ec,0)
   5841 script   RET   write 0
   5841 script   CALL  gettimeofday(0xbfbfe3f8,0)
   5841 script   RET   gettimeofday 0
   5841 script   CALL  select(0x5,0xbfbfe46c,0,0,0xbfbfe454)
   5841 script   RET   select 1
   5841 script   CALL  read(0,0xbfbfe4ec,0x400)
   5841 script   RET   read 0
   5841 script   CALL  write(0x4,0xbfbfe4ec,0)
   5841 script   RET   write 0
   5841 script   CALL  gettimeofday(0xbfbfe3f8,0)
   5841 script   RET   gettimeofday 0
   5841 script   CALL  select(0x5,0xbfbfe46c,0,0,0xbfbfe454)
   5841 script   RET   select 1
 repeated ad inifinitum.

From: Michiel Boland <michiel@boland.org>
To: Colin Percival <colin.percival@wadham.ox.ac.uk>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/72501: script(1) loops after EOF is read
Date: Fri, 15 Oct 2004 14:16:18 +0200

 >   Can you tell me anything more which might help me in trying
 > to reproduce this?
 
 My shell is /usr/local/bin/bash (bash-2.05b.007_2 from ports)
 This might also have something to do with it.

From: Brad Huntting <huntting@glarp.com>
To: bug-followup@FreeBSD.org, michiel@boland.org
Cc:  
Subject: Re: bin/72501: script(1) loops after EOF is read
Date: Sat, 14 Jul 2007 09:30:40 -0600

 FYI:  I am still seeing this behaviour when portupgrade invokes
 script(1).  I too use /usr/local/bin/bash and invoke portupgrade
 by echoing commands to 'sudo batch' (yes, I still use the 'batch'
 command and no, I dont own a punch card reader too.  :-).
 
 When running protupgrade top usually shows script using about half
 the cpu with the other half used by typcially ruby18 or cc1.  ktrace
 shows that script process is doing alot of 0 length read()s:
 
 	 76101 script   1184424629.826016 RET   select 1
 	 76101 script   0.000091 CALL  read(0,0xbfbfdbb0,0x400)
 	 76101 script   0.000023 GIO   fd 0 read 0 bytes
 	       ""
 	 76101 script   0.000007 RET   read 0
 	 76101 script   0.000007 CALL  write(0x4,0xbfbfdbb0,0)
 	 76101 script   0.000012 GIO   fd 4 wrote 0 bytes
 	       ""
 	 76101 script   0.000007 RET   write 0
 	 76101 script   0.000008 CALL  gettimeofday(0xbfbfdac8,0)
 	 76101 script   0.000006 RET   gettimeofday 0
 	 76101 script   0.000008 CALL  select(0x5,0xbfbfdb30,0,0,0xbfbfdb18)
 	 76101 script   0.000015 RET   select 1
 	 76101 script   0.000007 CALL  read(0,0xbfbfdbb0,0x400)
 	 76101 script   0.000008 GIO   fd 0 read 0 bytes
 	       ""
 	 76101 script   0.000005 RET   read 0
 	 76101 script   0.000006 CALL  write(0x4,0xbfbfdbb0,0)
 	 76101 script   0.000007 GIO   fd 4 wrote 0 bytes
 	       ""
 	 76101 script   0.000005 RET   write 0
 	 76101 script   0.000006 CALL  gettimeofday(0xbfbfdac8,0)
 	 76101 script   0.000005 RET   gettimeofday 0
 	 76101 script   0.000006 CALL  select(0x5,0xbfbfdb30,0,0,0xbfbfdb18)
 	 76101 script   0.000007 RET   select 1
 	 76101 script   0.000006 CALL  read(0,0xbfbfdbb0,0x400)
 	 76101 script   0.000007 GIO   fd 0 read 0 bytes
 	...
 
 In this case script was run by portupgrade which was run by batch(1)
 which was queued using 'BATCH=yes sudo batch' from a bash (version
 3) shell.
 
 Please let me know what specific follow up info would be useful.
 
 
 brad
State-Changed-From-To: open->closed 
State-Changed-By: trociny 
State-Changed-When: Thu Oct 6 18:03:09 UTC 2011 
State-Changed-Why:  
Fixed (r225809). 

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