Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!cbmvax!vu-vlsi!colin
From: colin@vu-vlsi.UUCP (Colin Kelley)
Newsgroups: comp.sys.ibm.pc
Subject: Re: MSC signal() and free() problems
Message-ID: <574@vu-vlsi.UUCP>
Date: Tue, 20-Jan-87 22:15:23 EST
Article-I.D.: vu-vlsi.574
Posted: Tue Jan 20 22:15:23 1987
Date-Received: Wed, 21-Jan-87 22:20:26 EST
References: <558@vu-vlsi.UUCP> <117@interlan.UUCP>
Reply-To: colin@vu-vlsi.UUCP (Colin Kelley)
Organization: Villanova Univ. EE Dept.
Lines: 43
Summary: Summary of solution + 2 other questions

In article <117@interlan.UUCP> backman@interlan.UUCP (1014-Larry Backman) writes:
>> [my query about MSC signal not restoring SS:SP]
>
>	The reason you are getting DOS's stack is that you are trapping an
>	interrupt!  When ^C is hit, the SIGINT function will call your routine
>	as an interrupt handler .  It is your responsibility  as an interrupt
>	routine to set up your environment correctly.

Remember, I didn't take over an interrupt--I just called signal() to have
it done for me.  If MS-DOS requires that SS:SP be restored, then signal()
should set up some code to do this before calling my code.

Anyway, several other people acknowledged via mail that this is an MSC 4.0
bug (actually, MSC didn't change; it's just that it should have once MS-DOS
3.x decided to use its own stack).  The work-around is a very simple
assembly-language interface routine which first restores SS:SP, then jumps
into the real C code.  I'll be happy to e-mail you this code if you need it.

>	I am curious about your problems with free and malloc.  I am using them
>	very heavily and have not seen problems with them.  Could you provide
>	a code fragment?

I wrote such a code fragment, and was surprised to find that it didn't
exhibit the problem.  So I went back to the big program (which did exhibit
the problem) and set a breakpoint at the start of malloc() using CodeView.
It turns out that some long-forgotten routine was malloc()ing a few bytes
now and then but never freeing them.  I fixed this code and memory allocation
now works as expected (almost--see #2 below).  Sorry for crying wolf...

While I'm at it, I might as well throw out two other small MSC problems:

1. _fmalloc() and _ffree() are provided (they allow malloc()ing and free()ing
far pointers in program compiled with small data).  What about _frealloc()?
It isn't documented, but I tried calling it anyway.  It isn't there.  Was
this just an oversight at Microsoft, or is there a reason?

2. Memory which has been malloc()ed and then later free()d is never returned
to MS-DOS; hence any attempt to spawn() or otherwise run another program
may fail due to lack of memory, even if all of that memory has been free()d.
I remember seeing in the Lattice 3.10 manual that their compiler now took
care of this.  Any solutions or work-arounds for MSC 4.0?

	-Colin Kelley  ..{cbmvax,pyrnj,psuvax1,bpa}!vu-vlsi!colin