X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
X-Authentication-Warning: smtp3.ihug.com.au: Host p70-tnt1.syd.ihug.com.au [203.173.128.70] claimed to be acceleron
Message-ID: <009201c181c0$d703a9d0$0102a8c0@acceleron>
From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
To: "Charles Sandmann" <sandmann AT clio DOT rice DOT edu>,
   "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Cc: <djgpp-workers AT delorie DOT com>
References: <10112101636 DOT AA18311 AT clio DOT rice DOT edu>
Subject: Re: v2.03 refresh ready for review/testing
Date: Tue, 11 Dec 2001 08:18:57 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Reply-To: djgpp-workers AT delorie DOT com

> > 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.
I tried 2 configurations:-
1) I tried the go32-v2.exe from the updatd 2.03 zip files and it failed in
the same spot. mem /c & mem /d looked the same.
2) I tried the 2.04 go32-v2.exe and it failed in the same spot. I did a CVS
update and build on XP as I was building the updated 2.03 on the 98 box.


> > 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?
There should be no exe's with unixy sbrk set.

Just a note about the psp issue that in CVS dosexec.c has a call to
__maybe_fix_w2k_ntvdm_bug(void)  which relates to a psp issue. The call is
not in the updated 2.03 sources.