Mail Archives: djgpp/2001/06/25/08:15:04.1
On Sun, 24 Jun 2001 10:58:32 +0300 (IDT), Eli Zaretskii
<eliz AT is DOT elta DOT co DOT il> sat on a tribble, which squeaked:
>I cannot define it precisely because the critical number of recursive
>invocations depends on the size taken by the automatic variables.
The number of invocations, no; the stack's size in bytes, yes; that
and the number and types of automatics and calloc's in a recursive
function should allow at least an order-of-magnitude estimate of the
maximal "safe" depth.
>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.
Thanks. To check for overflow I'll add lines to the recursive parts to
make the program scream and die if this gets below, say, 16k.
However, shouldn't the host (or whatever manages access protection) be
detecting if the stack is overflowed? There is a sigstackfault or
something similar. I've seen it some years ago from some misbehaving
program or another. Surely walking off the end of the stack is like
walking off the end of an array: it will trigger an exception, like
SIGSEGV for the latter case. If not, perhaps it should...
>See my other messages in this thread. CWSDPMI didn't crash...
Then why was the exception message generated inside CWSDPMI without a
traceback, instead of by whatever the usual mechanism is?
>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.
How can the tables get damaged? For a wild pointer to run into the
exception tables, it has to run out of its normal bounds, and cause a
SIGSEGV, doesn't it?
>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.
Those limitations don't apply to CWSDPMI. It can add non-standard
features and DJGPP can compile code to use them, so long as the same
code will work (perhaps generating poorer traceback info) under other
hosts such as Windoze.
>For example, the exception handlers cannot be bulletproof if
>they aren't write-protected (your program could--and probably
>did--scribble over them)...
Aren't the exception handlers protected against being scribbled on by
user code? I.e. outside the program's own allowed address range?
Perhaps they should be, so a program would segfault before trashing
them. Then there'd be a traceback, and the crash would be closer to
when the problem actually originates.
--
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 -