From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10205191837.AA20914@clio.rice.edu>
Subject: Re: Re[4]: emacs under w2k
To: lauras AT softhome DOT net
Date: Sun, 19 May 2002 13:37:35 -0500 (CDT)
Cc: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii), djgpp-workers AT delorie DOT com
In-Reply-To: <17244558826.20020519124811@softhome.net> from "Laurynas Biveinis" at May 19, 2002 12:48:11 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

> OK, I've followed your advice, and the problem (the old good abort,
> not SIGTRAP, still seems to happen at lcall. So as far as falsiness
> of this alert is concerned, only SIGTRAP is false...

<snip>

> What I don't get is how I supposed to look into code called by lcall?

the lcall is a fairly small (it's in sbrk16.asm) and does the following:

1) swaps stacks to a local stack (might cause problems with NTVDM?)
2) resizes memory block
3) resets the base of cs and ds selectors (note: ds alias's base is not
   changed until several hundred instructions later, so there is a 
   short term inconsistency - which might cause problems - any exception
   at this point would probably kill ntvdm).
4) swaps back to original stack

The reset of DS alias base so much later is really a bug; it's also in
an crt0.s section of code which is common when it should be specific to
the unixy sbrk() code section.  I'm not sure if that would cause an 
NTVDM crash (maybe if we are having hardware interrupts or exceptions 
happening in that time window?)

It would probably be best to fix the 16-bit helper to set the ds alias
base, or move this code to inside the section where interrupts are 
disabled.  This may not help the observed problem at all; it may just be
a bug in the resize DPMI memory block call (seen before, not commonly
used DPMI call).