From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto.edu with SMTP id <2688>; Sat, 15 Aug 1992 21:17:20 -0400
Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1)
	id AA04421; Sat, 15 Aug 92 18:16:03 PDT
Received: by netapp.netapp (4.1/SMI-4.1)
	id AA18161; Sat, 15 Aug 92 01:07:48 PDT
Date:	Sat, 15 Aug 1992 04:07:48 -0400
From:	netapp!byron@netcom.com (Byron Rakitzis)
Message-Id: <9208150807.AA18161@netapp.netapp>
To:	rc@hawkwind.utcs.toronto.edu
Subject: ^C leak

It appears to be in yacc.

Some yacc's call malloc to create their token stack, while some yacc's
have a fixed stack size. Now, rc calls yyparse which calls yylex which
calls read. An interrupt in read causes the signal to be trapped before
any more tokens can be returned to yacc so that it may either call
YYABORT or YYACCEPT (the two macros which also free up the yacc stack
space).

Obviously, the reason why the leak is not apparent at any time but when
a command is being typed is because the interrupt must occur while yacc
is active.

I would argue that this is a bug in yacc, given that it's extremely
difficult, if not impossible, to do exception processing given this
model. Perhaps yacc should supply a callback function to free memory,
or perhaps it should not call malloc in the first place. I'll see what
I can do about working around this. The fix is probably odious:
exception handling will have to be context-sensitive ("are we in a
stack frame containing yyparse?") and there will have to be some
automagical way of simulating a ^C through yacc. As I said, I don't
know if it's possible to fix.

In the meantime, you can always get rid of the leak by compiling rc
with a yacc that does not use malloc.  (old berkeley yacc is definitely
one of these, and it's probably in the bsd-sources tree. I got my
y.tab.c from a NeXT running such a yacc)

Depressing, eh? Does anyone have any better ideas?