Mail Archives: djgpp/2001/06/25/22:00:05.1
On Mon, 25 Jun 2001 15:42:31 +0300 (IDT), Eli Zaretskii
<eliz AT is DOT elta DOT co DOT il> sat on a tribble, which squeaked:
>> 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.
Okay, so you're saying an application crashes, whereupon either a
traceback is emitted or not, depending apparently on whether the DPMI
host or some other associated "attachment" detects the access
violation. The DPMI host produces poorer info. Is there a way to
ensure the other "attachment" is always the first one to detect the
violation?
> - 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.
All it looks at is the current CPU state at the time of the crash, and
the return addresses on the stack, from what I've seen. Unless the
very addresses that determine where the stack *is* got scrogged, I
don't see the problem. Of course, if the stack got scribbled on the
precious return addresses could have been overwritten with
gobbledygook...
>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.
Exactly what would user code have to be doing to mangle the SS
selector? I'd imagine typical numerical code with little pointer
arithmetic wouldn't be capable of doing so, except by provoking a bug
in a library function perhaps. (Allegro? That undoubtedly does all
kinds of selector hacks to do fullscreen graphics from within DPMI and
PM...) Well, if it stays away from calloc(), since a wild pointer on
the stack instead of the heap would easily trash the data structures
involved in printing tracebacks among other things.
>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.
I have had exceptions cascade before. E.g. I get segfault, symify just
says some stuff about __djgpp_exception_table or such. Older versions
could enter an infinite loop in this way, requiring the DOS box be
neck pinched from Windoze (or, outside of Windoze, a full-blown
reboot). I assume your above-mentioned CWSDPMI feature was introduced
to catch this and exit the loop. Unfortunately, it is beginning to
look like it may be getting applied overzealously.
>The application is dying horribly, not the DPMI host.
Your original statement was either incorrect then or unclear and
ambiguous; I read it as saying that CWSDPMI crashed.
--
Bill Gates: "No computer will ever need more than 640K of RAM." -- 1980
"There's nobody getting rich writing software that I know of." -- 1980
"This antitrust thing will blow over." -- 1998
Combine neo, an underscore, and one thousand sixty-one to make my hotmail addy.
- Raw text -