>Number:         8414
>Category:       lib
>Synopsis:       sh(1) loses badly with ^C and `new' malloc()
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    lib-bug-people (Library Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 14 16:50:01 1999
>Last-Modified:
>Originator:     Charles M. Hannum
>Organization:
        Internetwork Hacker
>Release:        -current
>Environment:
        n/a


>Description:
        When sh(1) gets a SIGINT inside malloc(), the malloc()
        recursion code trips, and all future allocations fail, causing
        the shell to become useless.

>How-To-Repeat:
	Do this a few times (where ^G is an actual control-G):

	$ while :; do echo -n ^G; done
	[wait a second, then type ^C]
	[repeat]

	Eventually, you'll get:

	$ while :; do echo -n ^G; done
	sh in malloc(): warning: recursive call.
	sh in malloc(): warning: recursive call.
	Out of space
	$ 

	Now here's the best part.  If I type:

	$ ps

	The ps(1) command runs, but when it exits, it appears that the
	shell actually resumes the while(1) loop!  If I send it a
	SIGINT from another window, I then get an endless stream of:

	sh in malloc(): warning: recursive call.
	Out of space
	sh in malloc(): warning: recursive call.
	Out of space
	[etc.]

>Fix:
	Protect all malloc(3) and realloc(3) calls with INTON/INTOFF?
	What about library routines that use malloc(3)?

>Audit-Trail:
>Unformatted: