Date: Sun, 28 May 2000 10:46:01 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Charles Sandmann cc: djgpp-workers AT delorie DOT com Subject: Re: W2k In-Reply-To: <10005272221.AA17175@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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?