Date: Tue, 24 Apr 2001 00:41:16 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: theowl AT freemail DOT c3 DOT hu Message-Id: <2427-Tue24Apr2001004115+0300-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9 CC: sandmann AT clio DOT rice DOT edu, djgpp-workers AT delorie DOT com In-reply-to: <3AE4B120.2679.298CA28@localhost> (theowl@freemail.c3.hu) Subject: Re: win2000/ntvdm/djgpp (fwd) References: <3AE460F5 DOT 18608 DOT 15FA3F3 AT localhost> <3AE4B120 DOT 2679 DOT 298CA28 AT localhost> 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 > From: "The Owl" > Date: Mon, 23 Apr 2001 22:48:00 +0200 > > > I usually like to be sure we are on the right track with these tricky > > problems, so reality checks from time to time don't hurt. But if you > > already checked that, or if you are sure testing this is redundant, I'm > > happy. > > i provided that small makefile example because i beleive i know exactly > what happens regarding this particular ntvdm crash issue and it was > supposed to prove it ;-). but if you need deeper info, i can provide > all the disassembly from ntvdm as well. Thanks, that won't be necessary. I have no reason to doubt your conclusions. > > This means we need to make sure the parent doesn't exit before it gets a > > chance to call 21/50. One possibility that the parent could exit right > > away is if the user pressed Ctrl-C or Ctrl-BREAK during the time the > > child was running. If the parent didn't mask SIGINT, it will abort as > > soon as it touches its data (this passing of SIGINT up the process group > > is a feature of DJGPP). I will have to think how to do this; suggestions > > welcome. > > well, i do not know how exactly events transpire in the above situations, Very simple: each DJGPP program hooks the keyboard interrupt, and when Ctrl-C is detected, the interrupt handler invalidates the DS selector (by resetting its limit to 4KB, the null page) and does an IRET. Thereafter, whenever the program is back in its normal execution thread, in protected mode, and touches any of its data or the stack, it GPFaults. The GPF handler consults a flag variable set by the keyboard interrupt handler, sees that the exception was triggered by Ctrl-C, restores the original DS limit, and calls ``raise(SIGINT);''. However, since the keyboard handler chains to the previous one, the parent (and its parent, etc.) also knows that Ctrl-C was pressed, and the parent's DS is invalidated as well. When the child exits, the parent will thus immediately trigger its own GPF and jump to the SIGINT handler, even before it calls 21/50. The default SIGINT handler aborts the program. > what i can say for sure is that two dpmi app exits without any direct > PSP setting or dpmi app start in between will trigger the bug in ntvdm. > > now whether the proposed workaround will work for all possible execution > paths or not, i could not tell you. for now i think most of us would be > happy to have something that works in the most generic case(s) (which > the int 21/50 after a child returns should do). I have an idea. Is it true that _running_ when _CurrentPSPSelector is zero is okay, and that only _exiting_ when it is zero causes NTVDM to crash? If so, we could set the PSP in the exit code. This would solve both the normal spawn and the case of abnormal termination via Ctrl-C, because the parent will restore its PSP just before it exits. Comments? > > So you are saying they wanted to avoid leaking DPMI selectors, which is > > known to happen on NT4, and introduced this bug in the process. Yes, > > that would make sense. > > actually, it is not about freeing selectors but freeing virtual memory. > if i am not mistaken, associated selectors are still leaked (or at least > freed at a different time). Yes, NT4 leeks memory as well as selectors.