Date:	Mon, 25 Jun 2001 15:26:01 +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:	<3b372211.237764748@news.primus.ca>
Message-ID:	<Pine.SUN.3.91.1010625151332.2920E-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:

> >> >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.

- Raw text -