Mail Archives: djgpp-workers/2001/04/23/16:51:26
> 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.
> 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,
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).
> 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).
- Raw text -