Date: Mon, 25 Jun 2001 15:26:01 +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: <3b372211.237764748@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: > >> >No, I blame it on you: it's your bug that caused a GPF inside CWSDPMI. > >> > >> There are clearly two bugs here: > >> 1. My code crashed. Ergo, it has a bug. > > > >Yes. > > > >> 2. CWSDPMI code crashed. Ergo, it has a bug. > > > >No, CWSDPMI didn't crash. Where do you think that message with > >registers come from? CWSDPMI detected the GPF, printed the message, > >aborted the program, then exited. > > This is in contradiction to your earlier claim. Earlier you said that > traceback I posted was a CWSDPMI crash instead of a user-code crash, > albeit presumably triggered by a user-code crash. No, I said that the GPF happened inside CWSDPMI. I didn't say CWSDPMI crashed, see above. > >When GPF's happen inside CWSDPMI, it usually means that the > >application's memory or exception table is so badly scrogged that it > >doesn't make sense to let the application code run. > > The latter is a general description of why we have access protections > and things like SIGSEGV rather than simply letting an errant program > scribble out of bounds. Please explain this, because I cannot make sense out of this sentence. How can you protect a program which, for example, calls a DPMI service to reset the segment limit to some small value, like 4KB? That's something a program might legitimately do, and should be able to do. In fact, every DJGPP program does that when you press Ctrl-C (that's how SIGINT works in DJGPP). Given that you do want a program to be able to do such things, it's clear that a program can then try to dereference some of the memory it now doesn't own, and will quite predictably get a GPF. And I really just described a very simple scenario where freedom of programming comes at the expense of extra protection. So access protection is not relevant here: it happens too late (that's when GPF is generated). By that time, a program could do so much harm to itself that it is not safe to let it continue run, even if just for the purpose of printing the traceback. So CWSDPMI doesn't let the program run at all, it commits suicide before more damage could be done by the runaway program. That _is_ protection at its best! > What remains unexplained here is that CWSDPMI is dying horribly I already explained in so many ways that it does not die. Evidently, I cannot get the point across to you; I give up. > So in the meantime, are there any > suggestions as to how to get a meaningful traceback in this case? Yes: run the program under a debugger, as I suggested long ago. Either you will be able to get a more meaningful traceback, or, if the debugger cannot do that as well, at least you will be able to single step the program until it blows and see exactly where does it blow up. Then you could (in another debugging session) poke around several insructions before it blows up and see what goes wrong.