From: invalid AT erehwon DOT invalid (Graaagh the Mighty) Newsgroups: comp.os.msdos.djgpp Subject: Re: Peculiar behavior of program. Organization: Low Charisma Anonymous Message-ID: <3b37e10a.286661752@news.primus.ca> References: X-Newsreader: Forte Free Agent 1.11/32.235 Lines: 70 Date: Tue, 26 Jun 2001 01:18:01 GMT NNTP-Posting-Host: 207.176.153.91 X-Complaints-To: news AT primus DOT ca X-Trace: news1.tor.primus.ca 993520518 207.176.153.91 (Mon, 25 Jun 2001 21:55:18 EDT) NNTP-Posting-Date: Mon, 25 Jun 2001 21:55:18 EDT To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Mon, 25 Jun 2001 15:42:31 +0300 (IDT), Eli Zaretskii 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.