Mail Archives: djgpp-workers/2001/04/23/17:45:45
> From: "The Owl" <theowl AT freemail DOT c3 DOT hu>
> 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.
- Raw text -