Date: Mon, 25 Jun 2001 15:42:31 +0300 (IDT) From: Eli Zaretskii 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk On Mon, 25 Jun 2001, Graaagh the Mighty wrote: > On Sun, 24 Jun 2001 10:56:05 +0300 (IDT), Eli Zaretskii > 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.