From hoek@beast.cdrom.com Sun Aug 29 21:00:58 1999
Return-Path: <hoek@beast.cdrom.com>
Received: from beast.cdrom.com (beast.FreeBSD.ORG [204.216.27.28])
	by hub.freebsd.org (Postfix) with ESMTP id C0B6614BD5
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 29 Aug 1999 21:00:58 -0700 (PDT)
	(envelope-from hoek@beast.cdrom.com)
Received: (from hoek@localhost)
	by beast.cdrom.com (8.9.3/8.9.3) id VAA52728;
	Sun, 29 Aug 1999 21:00:58 -0700 (PDT)
	(envelope-from hoek)
Message-Id: <199908300400.VAA52728@beast.cdrom.com>
Date: Sun, 29 Aug 1999 21:00:58 -0700 (PDT)
From: Tim Vanderhoek <hoek@beast.cdrom.com>
Reply-To: hoek@freebsd.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: /bin/sh: malloc() recursive call: segv
X-Send-Pr-Version: 3.2

>Number:         13463
>Category:       bin
>Synopsis:       /bin/sh does not handle interrupts correctly (?)
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Aug 29 21:10:00 PDT 1999
>Closed-Date:    Fri Jan 18 08:14:39 PST 2002
>Last-Modified:  Fri Jan 18 08:14:39 PST 2002
>Originator:     Tim Vanderhoek
>Release:        FreeBSD 4.0-CURRENT alpha
>Organization:
FreeBSD Project
>Environment:

-stable (3.2-S) and -current, although seems easier to reproduce on
-stable.

>Description:

$ while :; do echo -n ; done
^C
$ while :; do echo -n ; done
^C
$ while :; do echo -n ; done
sh in malloc(): warning: recursive call.
sh in malloc(): warning: recursive call.
Segmentation fault (core dumped)

>How-To-Repeat:

As above, enter "while :; do echo -n ; done" repeatedly and 
interrupt it.  When it does die, it dies immediately when the last
while command is entered (ie. not at ^C).

I suspect this is a more generic problem than this instance of it suggests.

Sometimes 20 or more iterations must be completed before it finally
segvs.  Sometimes far fewer...

>Fix:

Hope you get lucky?

>Release-Note:
>Audit-Trail:

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: hoek@FreeBSD.ORG
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/13463: /bin/sh: malloc() recursive call: segv 
Date: Mon, 30 Aug 1999 10:06:32 +0200

 On Sun, 29 Aug 1999 21:00:58 MST, Tim Vanderhoek wrote:
 
 > $ while :; do echo -n ; done
 > sh in malloc(): warning: recursive call.
 > sh in malloc(): warning: recursive call.
 > Segmentation fault (core dumped)
 
 This looks weird.
 
 Program terminated with signal 11, Segmentation fault.
 #0  0x805d644 in yywrap ()
 (gdb) back
 #0  0x805d644 in yywrap ()
 #1  0x805d681 in yywrap ()
 #2  0x805db05 in history ()
 #3  0x8051e3d in preadbuffer () at /usr/src/bin/sh/input.c:296
 #4  0x8058765 in xxreadtoken () at /usr/src/bin/sh/parser.c:776
 #5  0x80585b7 in readtoken () at /usr/src/bin/sh/parser.c:693
 #6  0x805762d in parsecmd (interact=1) at /usr/src/bin/sh/parser.c:145
 #7  0x80545b5 in cmdloop (top=1) at /usr/src/bin/sh/main.c:240
 #8  0x805452f in main (argc=1, argv=0xbfbfd668) at
 /usr/src/bin/sh/main.c:203
 
 How on earth does yywrap recurse on itself like that?
 
 /usr/src/usr.bin/lex/lib/libyywrap.c:
 int yywrap()
 	{
 	return 1;
 	}
 
 By the way, I can't reproduce the problem if I compile with -DDEBUG=2.
 
 Ciao,
 Sheldon.
 

From: Tim Vanderhoek <vanderh@ecf.utoronto.ca>
To: Sheldon Hearn <sheldonh@uunet.co.za>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/13463: /bin/sh: malloc() recursive call: segv
Date: Mon, 30 Aug 1999 13:01:16 -0400

 On Mon, Aug 30, 1999 at 10:06:32AM +0200, Sheldon Hearn wrote:
 > 
 > How on earth does yywrap recurse on itself like that?
 
 This is what I get if I set malloc_options to AX,
 
 Program terminated with signal 6, Abort trap.
 #0  0x806fbd0 in kill ()
 (gdb) bt
 #0  0x806fbd0 in kill ()
 #1  0x808e568 in abort ()
 #2  0x808d0db in isatty ()
 #3  0x808d0fb in isatty ()
 #4  0x808e124 in malloc ()
 #5  0x8059ff2 in yywrap ()
 #6  0x805a042 in yywrap ()
 #7  0x805a5db in history ()
 #8  0x8050420 in preadbuffer () at /usr/src/bin/sh/input.c:297
 #9  0x8055cf5 in xxreadtoken () at /usr/src/bin/sh/parser.c:776
 #10 0x8055b11 in readtoken () at /usr/src/bin/sh/parser.c:693
 #11 0x8054da9 in parsecmd (interact=1) at /usr/src/bin/sh/parser.c:145
 #12 0x805254b in cmdloop (top=1) at /usr/src/bin/sh/main.c:244
 #13 0x80524d3 in main (argc=1, argv=0xbfbfdb48) at
 /usr/src/bin/sh/main.c:207
 #14 0x80480ed in _start ()
 (gdb) print suppressint
 $1 = 1
 
 I don't know if that value for suppressint is correct.  I tend to
 suspect it is.
 
 It's got to be something to do with the signal that starts scrambling
 memory.  Have a look at this:
 
 # while :; do echo -n ; done
 ^C
 # asdfasdfasdfjkl
 asdfasdfasdfjkl: not found
 # while :; do echo -n ; done
 ^C
 # asdfasdfasdfasd
 asdfasdfasdfasd: not found
 # while :; do echo -n ; done
 ^C
 # asdfasdfahwefuiawhefouiaweh
 sh in malloc(): error: recursive call.
 Abort trap (core dumped)
 
 [malloc_options="AX"]
 
 Martin Cracaeur was the last person to touch the sh signal handling,
 but I'm not sure if he touched anything unrelated to trap.c.
 
 The signal handlers (onsig() and onint()) look pretty benign.  I can
 reproduce it both with and without rootshell.  [See the patch at the
 end of this message, though].
 
 
 > By the way, I can't reproduce the problem if I compile with -DDEBUG=2.
 
 Try harder.  :-)  It reproduces for me when compiled with -DDEBUG=2.
 
 
 If I apply the following patch, I cannot reproduce the problem.
 
 Perhaps this is enough to give someone who knows more about the sh
 sources than me a quicker start on the problem.  [I assume it's not
 the correct fix, although for all I know, it could be...  :-]
 
 --- ~eval.c	Mon Aug 30 12:54:40 1999
 +++ eval.c	Mon Aug 30 12:57:32 1999
 @@ -289,7 +289,9 @@
  	loopnest++;
  	status = 0;
  	for (;;) {
 +		INTOFF;
  		evaltree(n->nbinary.ch1, EV_TESTED);
 +		INTON;
  		if (evalskip) {
  skipping:	  if (evalskip == SKIPCONT && --skipcount <= 0) {
  				evalskip = 0;
 @@ -306,7 +308,9 @@
  			if (exitstatus == 0)
  				break;
  		}
 +		INTOFF;
  		evaltree(n->nbinary.ch2, 0);
 +		INTON;
  		status = exitstatus;
  		if (evalskip)
  			goto skipping;
 
 
 -- 
 This is my .signature which gets appended to the end of my messages.
 
State-Changed-From-To: open->feedback 
State-Changed-By: mike 
State-Changed-When: Fri Jul 20 17:36:48 PDT 2001 
State-Changed-Why:  

Does this problem still occur in newer versions of FreeBSD, 
such as 4.3-RELEASE? 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=13463 

From: pavalos@theshell.com
To: freebsd-gnats-submit@freebsd.org, hoek@freebsd.org
Cc:  
Subject: Re: bin/13463: /bin/sh does not handle interrupts co
Date: Sat, 11 Aug 2001 22:38:28 -0700 (PDT)

 It still happens on my 4.4-PRERELEASE system. Source is from Aug. 11, 2001.
 
 --Pete
 
State-Changed-From-To: feedback->closed 
State-Changed-By: sheldonh 
State-Changed-When: Fri Jan 18 08:14:39 PST 2002 
State-Changed-Why:  
Automatic feedback timeout.  If additional feedback that warrants 
the re-opening of this PR is available but not included in the 
audit trail, please include the feedback in a reply to this message 
(preserving the Subject line) and ask that the PR be re-opened. 

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