delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/05/28/03:47:38

Date: Sun, 28 May 2000 10:46:01 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc: djgpp-workers AT delorie DOT com
Subject: Re: W2k
In-Reply-To: <10005272221.AA17175@clio.rice.edu>
Message-ID: <Pine.SUN.3.91.1000528104318.15881F-100000@is>
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

On Sat, 27 May 2000, Charles Sandmann wrote:


> If I touch the keyboard when gcc'ing alone, it seems to make no difference
> (still stable, maybe compiles slower when autorepeating ...)
> 
> If I touch the keyboard when running make, it does seem to usually cause
> crashes to happen immediately.
[snip]
> My conclusion is that Win2K's emulation is very reliable in one level of
> nesting, but a second nesting (3 levels) causes it to have problems in some
> cases.  I can run simple images nested 6 deep and they seem to work.  
> 
> It could be a simple issue of hardware interrupts when nested several levels
> deep or something.

Thanks for testing.

One thought that strikes me is that if this is about hardware
interrupt hooking, then what interrupt can be involved besides the
keyboard?  IIRC, we only hook Int 75h in addition to the keyboard.
Since it crashes even if the keyboard is not touched, I wonder what
will happen if the nested programs trigger FP exceptions?

Recently, Pierre Muller reported here a few problems that seem to
indicate that Windows 9X gets confused about Int 75h in nested
environments: if a child program triggers an FP exception, the
interrupt is delivered to the parent!  Perhaps something similar, but
more violent, happens in Win2K?  For example, the crashes could be
explained by FP exceptions in some unrelated piece of software that
just happens to run at the same time.  Given the NT4 problems with
hooking SIGFPE, this could be their logical sequel...

Another thing to try would be to run programs from REDIR.  The version
shipped with v2.03 toggles all exceptions before running the child
program, so it might reveal some additional information.  For example,
try running a compilation from Make, but through REDIR instead of
directly, possibly several nested REDIR's.

> FAULT ->77e89b01 e9d2030300       jmp     SetThreadContext+0x46 (77eb9ed8)

It seems to crash when it jmp's to one of its own routines.  How can that 
happen?

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019