From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9612291922.AA11785@clio.rice.edu>
Subject: Re: Problem with DJGPP programs in bash
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Sun, 29 Dec 1996 13:22:47 -0600 (CST)
Cc: Jerzy DOT Witkowski AT ii DOT uni DOT wroc DOT pl, djgpp AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.961223163401.2480A-100000@is> from "Eli Zaretskii" at Dec 23, 96 07:23:04 pm
Content-Type: text
Content-Length: 2042      

> > Second, the computer hangs sometimes.  This usually happens when I
> > execute `go32-v2 prog ; go32-v2' two or more times.  
> 
> Confirmed.  This indeed happens for me also when I run COFF image with 
> go32-v2.  Since this never happens from COMMAND.COM, I guess it's some 
> problem with go32-v2 not cleaning up correctly after the child exits.  In 
> one of my tests I got this message (from CWSDPMI, I guess):
> 
> Invalid TSS in RMCB at eip=3364, flags=3002
> eax=000a0001 ebx=000020d4 ecx=00000000 edx=00000020 esi=00b088a edi=000030d8
> ebp=000a7c58 esp=00003024 cs=e7 ds=3b es=33 fs=33 gs=eb ss=33 error=00e4

What this message means is that a HW interrupt or RMCB has been left hooked
when a nested image exited.  Something didn't clean up properly.  When the
HW interrupt triggered it tried to transfer control to an invalid CS (see
the error code).

The original V2 design to avoid these problems was to have each image have
a registry of RMCBs and hooked HW/RM interrupts.  On a system/exec/spawn/exit
call they would all be toggled to their original state, then restored 
immediately on return (so if they were left in a bad state, the parent image
would be defensive about it and fix them).  There were problems with this
(SIGINT passing, the window of DEATH between the child exit and the restore,
etc) so it never got resolved/finished/coded.  What should have been done was
to have a combination of the current "we expect the child to clean up 
completely" and "I'm the parent and I don't trust any child to do anything
right".  Too many tasks, not enough time...

With that said, there were also some gross assuptions in the debugger load 
code, which assumes it's the parent and doesn't need to clean up some things.
go32-v2 calls the debugger load code, and didn't clean up it's own interrupt
hooks/memory/selectors since it was assumed to be at the top level, and this
would be unnecessary.  GO32-V2 started out as a quick, 20 minute hack to be
able to execute unstubbed images - and evolved with no requirements...