[Haven't looked at this in any detail.  A glance through the CVS
signal handlers (mostly in main.c) should detect it if something
obvious is amiss

See patch.c (patch_cleanup) which calls free (but I'm not sure it did
in CVS 1.9).  So does Lock_Cleanup.  So do any of the signal handlers
which call stdio (e.g. via error()).  rcs_cleanup, main_cleanup.

See sigaction() in the standards (POSIX or Single Unix Spec) for a
list of the system functions which we are allowed to call.

Note that sprintf() is not signal-safe according to Single Unix Spec.
So main_cleanup shouldn't call it (which is not a problem since this
is a "can't happen" case).

-kingdon]

Date: Mon, 29 Dec 1997 15:35:48 -0700 (MST)
From: Keith Bostic <bostic@BSDI.COM>
To: bug-cvs@prep.ai.mit.edu
Reply-To: bostic@BSDI.COM


>Submitter-Id:   net
>Originator: 	 Keith Bostic
>Organization:
net
>Confidential:  no
>Synopsis:	cvs desn't take interrupts lightly:
>Severity:	non-critical
>Priority:	low
>Category: 	cvs
>Class:		sw-bug
>Release:	cvs-1.9
>Environment:
    	
System: BSD/OS forge.BSDI.COM 4.0 BSDI BSD/OS 4.0(Alpha) Kernel #13: Mon Dec 22 14:04:44 MST 1997 polk@demiurge.BSDI.COM:/home/polk/sys/compile/FORGE i386


>Description:
	My guess is that CVS calls malloc from an interrupt routine.

>How-To-Repeat:
	$cvs -q update sys
	U sys/i386/i386/i386_param.c
	M sys/sparc/include/ansi.h
	^?cvs in malloc(): warning: recursive call.
	out of memory
>Fix:
	None.