From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10205210418.AA15653@clio.rice.edu>
Subject:	Re: emacs under w2k
To:	djgpp-workers AT delorie DOT com
Date:	Mon, 20 May 2002 23:18:37 -0500 (CDT)
Cc:	lauras AT softhome DOT net, eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
In-Reply-To:	<10205201643.AA14265@clio.rice.edu> from "Charles Sandmann" at May 20, 2002 11:43:32 AM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
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

> My test program reliably fails with the current sbrk (taking down NTVDM)
> with the right input arguments (which can change from one run to the
> next ...).
> 
> Next plan was to try to unhook our keyboard handler (and maybe exception
> handlers) to see if it still crashes ntvdm.

Tried adding __djgpp_exception_toggle() before the sbrk() calls and it
no longer aborts under Win2K(), even with very large memory arena moves.

Did more tests - using values of "20000 100" is enough to get an 
abort for me.  It appears that when the arena is moved (20Mb of it) 
on the second sbrk takes a significant amount of time, and some 
event (interrupt?) happens in that time.  It then gets serviced after 
the move - or in the middle of it (ignoring the disable interrupt
call?) and boom.  I believe it is the key up event for the keyboard - 
if I hold the key down a little longer after the keypress (but not so
long that it autorepeats) I seem to be able to avoid the crash sometimes.
Luck? Not sure, but seems fairly reproducible.

There's no real easy way to restore just the keyboard handler that I
see without some dpmiexcp edits I didn't have time for.

Looking at the keyboard handler, it only appears to use CS (not DS
alias) - which leads me to believe that the "disable interrupts" 
call in sbrk() around the realloc dpmi call is being ignored.  So 
fixing the alias "window of breakage" wouldn't fix this (since it's
not used).

I don't know if a CLI would work better under Win2K either to prevent
this.  

I thought I would fill you in on what I found - no time for another day
or so.

Next step would be to disable the keyboard alone and see if it's 
solid; also to try adding a CLI call after the dpmi interrupt disable 
calls in crt0 to see if that helps.

So far it looks very much like a Win2K bug to me.

- Raw text -