Date: Sun, 24 Jun 2001 10:58:32 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: djgpp AT delorie DOT com Subject: Re: Peculiar behavior of program. In-Reply-To: <3b351935.104404794@news.primus.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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.