Mail Archives: djgpp/2001/06/24/06:09:41
On Sat, 23 Jun 2001, Graaagh the Mighty wrote:
> >As I said earlier, I'd first suspect some stack smashage, like a huge
> >automatic variable or extremely deep recursion.
>
> Well there's no huge automatic variables. There is recursion, but I
> don't think it ever goes "extremely deep". Define "extremely deep"
> more precisely and I can have another look.
I cannot define it precisely because the critical number of recursive
invocations depends on the size taken by the automatic variables.
You can use the `stackavail' library function to track the amount of
free stack at any point in your program. For example, you could add a
printf line which prints the result at interesting points, where you
think there might be lots of recusrion.
> >You misunderstand what happens: the exception (GPF) indeed happens inside
> >CWSDPMI, but the reason is outside CWSDPMI. So CWSDPMI bugs are not
> >relevant here; _your_ bugs are.
>
> Actually, both are. If CWSDPMI did a better job of not crashing, I'd
> have gotten e.g. a nice stack fault with traceback to aid in
> debugging.
See my other messages in this thread. CWSDPMI didn't crash, it
printed the message, aborted your program, and then exited itself.
> I've also had apps crash, and then the djgpp_exception_foo stuff
> proceeds to crash, causing me to get a traceback in djgpp code instead
> of my own code.
This is consistent with the fact that CWSDPMI rather than the
application prints the crash message: having the exception tables
damaged is one of the cases when CWSDPMI aborts the program rather
than letting it abort itself. Letting the application run when the
exception handlers are toast is very dangerous, so CWSDPMI doesn't.
For example, imagine the case where the application makes all of its
data and code segment invalid. There's nothing CWSDPMI can do in
this case except abort it.
> If there's one thing that really seriously needs
> improving in djgpp, it's making crashes more consistently a) produce
> useable tracebacks in the machine (i.e. the default exception handlers
> and CWSDPMI need to be bulletproof, or at least closer to that ideal
> than they are) and b) not cause spontaneous reboots or other screwball
> phenomena that make things *really* difficult.
It's next to impossible to make this much better, given all the
limitations of the DPMI spec and its implementations in most popular
hosts. For example, the exception handlers cannot be bulletproof if
they aren't write-protected (your program could--and probably
did--scribble over them), but you cannot write-protect the code
segment due to limitations DPMI imposes on exception processing.
Perhaps a multi-megabuck venture with people who are payed to do it
could write a better DJGPP. But DJGPP wasn't written that way. Still
isn't.
- Raw text -