From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <10005290101.AA16829@clio.rice.edu> Subject: Re: W2k To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii) Date: Sun, 28 May 2000 20:01:41 -0500 (CDT) Cc: djgpp-workers AT delorie DOT com In-Reply-To: from "Eli Zaretskii" at May 28, 2000 10:46:01 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 > 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. Interesting test results: The nesting 3 level deep sequence: make / redir /echo2 shows frequent failures The nesting 3 level deep sequence: redir /make /echo2 seems to be stable The nesting 3 level deep sequence: redir / gcc -c -O2 *.c seems to be stable The nesting 3 level deep sequence: go32-v2 \djgpp\gcc.exe -O2 -c @c.inp seems to be stable (it won't take *.c for some reason, and this is 3 level nesting - does go32-v2 unhook interrupts?) So, maybe the unhooking helps if it is done at the top level? I did see one isolated failure running gcc standalone - immediately after booting into NT (the .exe image created was corrupt also) but that was an isolated incident that I can't reproduce). > > 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? Well it is a microsoft product ... It could be due to a code segment limit violation, or a page fault. The address in () looks semi-reasonable but is larger than anything else in the tiny segment of code we see. Who knows.