Mail Archives: djgpp/2001/06/26/09:10:19
On Tue, 26 Jun 2001, Graaagh the Mighty wrote:
> >No, I said that the GPF happened inside CWSDPMI. I didn't say CWSDPMI
> >crashed.
>
> A rather fine distinction it seems.
No, it isn't: a GPF is not necessarily CWSDPMI's fault, because
CWSDPMI needs to use the application's selectors in some cases.
> Perhaps you should seek employment at Microsoft. ;-)
If that is supposed to be a thank-you for the time I spend trying to
explain things to you, you have a strange way of expressing gratitude.
> >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.
See above: CWSDPMI sometimes needs to use application's selectors and
data. Like when it jumps to the exception handlers installed by the
application. In such cases, the GPF happens inside CWSDPMI, but
CWSDPMI is not the one to blame.
> >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?
Because most of access violations happen by using wild pointers, so
the core data structures (exception handlers and selectors) are
intact. Under these circumstances, it is safe to pass the exception
to the application, which will then generate a 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!
>
> It's *too* good if it suppresses the output of essential debugging
> information.
Only if it has no choice. Suppressing the traceback is better then
overwriting your hard disk partition table.
> >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.
See my other message: I think if you upgrade, these problems will go
away.
> 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.
I didn't mean to single-step all the way from the startup code. You
should find a way to put a breakpoint that will only fire at the right
moment, for example using the breakpoint condition facilities of GDB.
> Breakpoints present problems where recursion is involved.
Conditional breakpoints can solve this as well.
> 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.
GDB breakpoints support all the conditions you could put into
printf's, and then some. IIRC, FSDB also supports conditional
breakpoints (but I won't recommend using FSDB unless GDB cannot help,
for some reason).
- Raw text -