From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: Peculiar behavior of program. Date: 26 Jun 2001 09:09:19 GMT Organization: Aachen University of Technology (RWTH) Lines: 101 Message-ID: <9h9jfv$khe$1@nets3.rz.RWTH-Aachen.DE> References: <3b37df15 DOT 286160341 AT news DOT primus DOT ca> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 993546559 21038 137.226.32.75 (26 Jun 2001 09:09:19 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 26 Jun 2001 09:09:19 GMT Originator: broeker@ To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Graaagh the Mighty wrote: [...] > Sure. The program has a bug, commits an access violation, and an > access fault crash occurs. With, one would hope, a traceback, complete > with the offending selector limit and the offending accessor > instruction. If the bug were as simple as a mere access violation, then that's exactly what would happen. But by design of DPMI and related limitations, some loopholes have to be left open by which a bug will overwrite crucial portions of memory (like the program's own page tables, or return addresses and other important stuff somewhere in the stack), _without_ triggering any CPU exception. Speaking figuratively: once you have a program shooting itself in the foot, it may occasionally have be as unlucky as to blow away both it's legs at knee level, in one shot. No surprise it can't hobble around on one foot to be able to inspect the damage in the other, in such case. > Then why do access violations produce tracebacks 99% of the time? Because 99% of the time, you only hit one toe, or at least only one foot. > It's *too* good if it suppresses the output of essential debugging > information. You're assuming that this essential debugging information still exists and can be accessed by the DPMI server --- but sometimes, a crash is bad enough that this simply isn't true. >>I already explained in so many ways that it does not die. Evidently, I >>cannot get the point across to you; I give up. > Okay, so it plays possum: it looks an awful lot like it died, but it > didn't? It did die, but by suicide, not by accident, as you keep claiming it did. >>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. Now, look who's talking. Last I read, you didn't even have the current version of DJGPP installed. So no you're complaining about something not being state-of-the-art??? >>...or, if the debugger cannot do that as well, at least you will be >>able to single step the program until it blows and see exactly where >>does it blow up. > Unfortunately, both debuggers blow up first -- before even reaching > their first interaction prompt (is the executable itself being > generated "bad" by the compiler then?) -- Well, if you never bother to set a breakpoint, and the crash was only ever detected by the DPMI server, not by the app itself, that's to be expected. The debugger is part of the app, sort-of, so if the app can't detect the crash in time, neither will the debugger. > and even if they didn't, such single stepping could take years given > how involved the calculations are this software makes. Learn how to use the debugger properly, and it'll be nowhere near that hard. Learn about breakpoints, break conditions, ignore counts, and display statements. Nobody said you were supposed to single-step through the whole execution of that program, did we? > dated, 400MHz box mind you. Breakpoints present problems where > recursion is involved. That's what breakpoint conditions were invented for. > 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. The same conditions can be applied to breakpoints inside the debugger. But nothing's wrong about debugging printf()s, per se: they can still be useful to find a suitable set of > Unfortunately, when the crash is usually fatal to the OS, these become > less useful too. "Fatal to the OS"? Now, when did *that* come up, before? Up till now, it only caused the DPMI server to terminate the client and itself, but not the OS. So either you forgot to tell about it before, or you're talking nonsense now --- you decide. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.