From: invalid AT erehwon DOT invalid (Graaagh the Mighty) Newsgroups: comp.os.msdos.djgpp Subject: Re: Peculiar behavior of program. Organization: Low Charisma Anonymous Message-ID: <3b3723d5.238217279@news.primus.ca> References: X-Newsreader: Forte Free Agent 1.11/32.235 Lines: 64 Date: Mon, 25 Jun 2001 11:51:25 GMT NNTP-Posting-Host: 207.176.153.32 X-Complaints-To: news AT primus DOT ca X-Trace: news2.tor.primus.ca 993470911 207.176.153.32 (Mon, 25 Jun 2001 08:08:31 EDT) NNTP-Posting-Date: Mon, 25 Jun 2001 08:08:31 EDT To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Sun, 24 Jun 2001 10:58:32 +0300 (IDT), Eli Zaretskii 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.