Date:	Mon, 25 Jun 2001 15:42:31 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	djgpp AT delorie DOT com
Subject:	Re: Peculiar behavior of program.
In-Reply-To:	<3b372379.238124895@news.primus.ca>
Message-ID:	<Pine.SUN.3.91.1010625152859.2920G-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 25 Jun 2001, Graaagh the Mighty wrote:

> On Sun, 24 Jun 2001 10:56:05 +0300 (IDT), Eli Zaretskii
> <eliz AT is DOT elta DOT co DOT il> sat on a tribble, which squeaked:
> 
> >Note that CWSDPMI didn't crash: it is CWSDPMI that printed this
> >message.  Then it exited.
> 
> Well, why is there no traceback for the user code then?

Because the traceback you are used to see comes from the application, not 
from CWSDPMI.

> Normally when
> the host detects an access violation in user code, it prints a
> traceback, e.g. the segfault I posted in another thread, as well as
> terminating the user code.

Not true: the traceback is not printed by the DPMI host.  What happens is 
this chain of events:

  - application code does something that violates protection;

  - the CPU generates an exception (GPF in your case, but could be 
    something else, like Page Fault, for example);

  - the exception is delivered to the application;

  - the application prints its traceback (by walking the run-time stack), 
    and then exits.

The exception is delivered to the application because the DJGPP startup 
code hooks all the CPU exceptions (see exceptn.S and dpmiexcp.c in the 
library).  The code which prints the traceback is right there in 
dpmiexcp.c as well.  That code is specifically written to use as few 
system calls and as few application data as possible, because that code 
typically runs in a very unstable environment, and therefore accessing 
some data could well cause yet another exception.

But, however cautious that code is, it cannot cope with all possible 
problems.  For example, imagine that the SS selector is invalid: in that 
case, calling library functions will just cause another exception.

There can be trouble more serious than that: the exception tables set up 
by the startup code could be damaged: for example, they could point to 
invalid locations.  In those cases, or when an exception happens while a 
previous exception is being processed, CWSDPMI doesn't pass the exception 
to the application, but instead handles it itself.  That's why you don't 
get the traceback: the code which prints it didn't get chance to run.

> Earlier you said there was no traceback
> because the host was dying horribly and not merely the user code.

The application is dying horribly, not the DPMI host.

- Raw text -