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: <10112101841.AA17909@clio.rice.edu>
Subject: go32-v2 memory chompage [was: Re: v2.03 refresh ...]
To: djgpp-workers AT delorie DOT com
Date: Mon, 10 Dec 2001 12:41:06 -0600 (CST)
Cc: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii), acottrel AT ihug DOT com DOT au (Andrew Cottrell)
In-Reply-To: <10112101636.AA18311@clio.rice.edu> from "Charles Sandmann" at Dec 10, 2001 10:36:42 AM
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

go32-v2 allocates dos memory to pass the command line
v2load allocates dos memory for the environment and command line
v2load allocates dos memory for the transfer buffer

(I think this explains the 3 sizes of blocks observed).

What's interesting is these are some of the few places which allocate
DOS memory in the entire library/toolchain (and they all get called from
go32-v2).  These all happen early in go32-v2 before we transfer to
the child.  

Now, we pass the child a stubinfo psp returned from a dos memory block
allocation... but it doesn't look like a valid DPMI psp selector to me.
We let the child "exit" back to us.  During that exit the child passes 
this bogus psp to NT as a set psp - what happens?  Then the child may 
do some operations to NTVDM/DPMI with an invalid psp?    This may be 
a reason to replace the current code with what I use in the patch :-)

I don't know why we wouldn't also see this under CVS if this is the
case.