From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from odin.INS.CWRU.Edu ([129.22.8.102]) by hawkwind.utcs.toronto.edu with SMTP id <2732>; Thu, 13 Aug 1992 09:45:54 -0400
Received:  by odin.INS.CWRU.Edu (5.65b+ida+/CWRU-1.5-ins)
	id AA12001; Thu, 13 Aug 92 09:44:23 -0400 (from chet for rc@hawkwind.utcs.toronto.edu)
Date:	Thu, 13 Aug 1992 09:34:59 -0400
From:	Chet Ramey <chet@odin.INS.CWRU.Edu>
To:	schwartz@groucho.cs.psu.edu
Subject: Re: memory leaks
Cc:	rc@hawkwind.utcs.toronto.edu, chet@odin.INS.CWRU.Edu
Reply-To: chet@po.CWRU.Edu
In-Reply-To: Message from schwartz@groucho.cs.psu.edu of Wed, 12 Aug 1992 22:08:12 -0400
Message-Id: <9208131334.AA02378.SM@odin.INS.CWRU.Edu>
Read-Receipt-To: chet@po.CWRU.Edu

> Is anyone (besides me) concerned about the memory leaks in rc1.4?  If
> you hit ^C you can watch your process size go up.  Depressing.  What do
> other shells do about this?

Bash has a fairly nice `unwind-protect' mechanism.  The interrupt handler
runs the unwind-protect list.  Bash is full of calls like

	begin_unwind_frame("tag");
	add_unwind_protect(free, string1);
	add_unwind_protect(close, openfd);
	add_unwind_protect (restore_signal_mask, oset);

		...

	run_unwind_frame("tag");

Look in the source file `unwind_prot.c' in the bash distribution.

ash and sh have a mechanism to `mark the stack' when allocating memory.
Then when they want to free it, they just unwind back to the previous
mark.

Chet

--
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu