X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10112101636.AA18311@clio.rice.edu>
Subject: Re: v2.03 refresh ready for review/testing
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Mon, 10 Dec 2001 10:36:42 -0600 (CST)
Cc: acottrel AT ihug DOT com DOT au (Andrew Cottrell), djgpp-workers AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.1011210130558.21947A-100000@is> from "Eli Zaretskii" at Dec 10, 2001 01:13:16 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> This clearly shows that some memory used up by go32-v2 is not released 
> when it exits.  (I's also possible that go32-v2 doesn't exit, but that 
> sounds unlikely.)

OK.  Andrew - a quick test please?  Rename the go32-v2 from the distribution
and try one from the cvs build and see if the problem goes away.  I will
double check that the go32-v2 is being built properly and check for 
patches which might have fixed things in CVS that I wasn't aware of.

> Charles, does ~40KB of low memory ring a bell?  I cannot figure out why 
> would go32-v2 need more than twice the size of the transfer buffer in 
> conventional memory...

the mem/d shows this 40Kb is actually many blocks.  Probably from 
multiple nested runs filling in the holes.  Only the 4100 (16K plus psp)
looks familiar - however the 1140/1240 appears alot and may be an 
environment size (command and mem show environment sizes of around 800).
I wonder if anything is left lying around that was rebuilt with unixy
sbrk - which also uses dos memory blocks?

  005D50      MSDOS        003A60     -- Free --
  0097C0      go32-v2      001140     Data
  00A910      go32-v2      000040     Data
  00A960      go32-v2      001250     Data
  00BBC0      go32-v2      004100     Data
  00FCD0      go32-v2      001140     Data
  010E20      go32-v2      000060     Data
  010E90      go32-v2      001240     Data
  0120E0      go32-v2      001140     Data
  013230      go32-v2      000070     Data
  0132B0      go32-v2      000070     Data
  013330      go32-v2      000070     Data
  0133B0      go32-v2      000060     Data
  013420      go32-v2      000070     Data
  0134A0      MSDOS        000BB0     -- Free --

I can see if I can reproduce this type of behavior in a simple 
environment.  If so, I can look at the contents of the blocks to see
what they were and figure out why the dos memory doesn't get cleared
up.  Strange, but a really good find.