Mail Archives: djgpp/2001/06/25/22:00:05
On Mon, 25 Jun 2001 15:26:01 +0300 (IDT), Eli Zaretskii
<eliz AT is DOT elta DOT co DOT il> sat on a tribble, which squeaked:
>No, I said that the GPF happened inside CWSDPMI. I didn't say CWSDPMI
>crashed.
A rather fine distinction it seems. Perhaps you should seek employment
at Microsoft. ;-)
>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.
Sure. The program has a bug, commits an access violation, and an
access fault crash occurs. With, one would hope, a traceback, complete
with the offending selector limit and the offending accessor
instruction.
>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.
Then why do access violations produce tracebacks 99% of the time?
According to your reasoning, there should be no tracebacks except for
hitting ctrl-break!
>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!
It's *too* good if it suppresses the output of essential debugging
information.
>I already explained in so many ways that it does not die. Evidently, I
>cannot get the point across to you; I give up.
Okay, so it plays possum: it looks an awful lot like it died, but it
didn't?
>Yes: run the program under a debugger, as I suggested long ago.
Unfortunately, the state of the art in debuggers has apparently yet to
become freely available, unlike e.g. that in compilers. I have two
crufty command-line debuggers that came with my setup, and neither of
these work.
>...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.
Unfortunately, both debuggers blow up first -- before even reaching
their first interaction prompt (is the executable itself being
generated "bad" by the compiler then?) -- and even if they didn't,
such single stepping could take years given how involved the
calculations are this software makes. When it works, and isn't slowed
down by multitasking or "hooked in" stuff like a debugger or profiler,
it can still take minutes to produce a result; this is on a slightly
dated, 400MHz box mind you. Breakpoints present problems where
recursion is involved. The only thing I've figured to fall back on is
the old standby: debugging printfs and their cousins, which unlike
breakpoints can be conditioned on all kinds of nice and intricate
conditions, so long as you carefully avoid side effects in the
conditions.
Unfortunately, when the crash is usually fatal to the OS, these become
less useful too.
--
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 -