- To: email@example.com
- Subject: Memory leak?
- From: "Mike Bilow, firstname.lastname@example.org" <mikebw@IDS.JVNC.NET>
- Date: Sat, 18 Jan 1992 07:46:55 EST
My system generally stabilizes with about 60-80K core left when running
under raw DOS, and I set my DV window to leave about 30-40K core worst
case when under DV. I have never seen the full version of my GRINOS go
under 30K core left when in a 610K window, and that would be an extreme
case with about 15 or 20 channels going at once.
As you know, I am running a version of PA0GRI NOS with my own changes.
Most of my changes are cycled back into Gerard's code, since I am not
anxious to have diverging NOS releases. One change I made, which I
believe Gerard has cycled in, is the "mem minheap" parameter, which
could be responsible for exactly the leakage you are seeing.
When shelling out to the DOS (!) or to the mailer (mail), NOS will make
a request to mallocw() for mem minhep bytes and then immediately free
them before shelling out. This guarantees that there will be this much
minimum free unallocated contiguous heap while in the shell. I did this
to prevent crashes that were occuring while shelled out, since a cal to
morecore() will always fail with the shell running. In fact, the way
that Borland C seems to work, if a call is ever made to coreleft() or
sbrk() or similar library functions with the shell running, then bad
memory information will continue to be returned by those functions even
after the shell has been terminated.
I admit that this was a kludge, but it did seem to work. The default
value of mem minheap, 12K, was chosen by trial and error, and is a bit
on the conservative side.
Still, this does not produce real leakage. It decreases the amount of
coreleft that you would otherwise see, which is exactly what it is
intended to do, but it should just give you a higher percentage of heap
that is free at any time, so you should be able to shell out day and
night if you like, and mem minheap should stop doing anything after a
couple of hours. Most of the crashes related to this were happening
when shelling out in the first 10 minutes after starting NOS, and that
was what I fixed.