From: invalid AT erehwon DOT invalid (Graaagh the Mighty) Newsgroups: comp.os.msdos.djgpp Subject: Re: Strange behavior of compiler. Organization: Low Charisma Anonymous Message-ID: <3b37e5df.287898614@news.primus.ca> References: X-Newsreader: Forte Free Agent 1.11/32.235 Lines: 57 Date: Tue, 26 Jun 2001 01:37:49 GMT NNTP-Posting-Host: 207.176.153.91 X-Complaints-To: news AT primus DOT ca X-Trace: news1.tor.primus.ca 993521711 207.176.153.91 (Mon, 25 Jun 2001 22:15:11 EDT) NNTP-Posting-Date: Mon, 25 Jun 2001 22:15:11 EDT To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Mon, 25 Jun 2001 16:10:13 +0300 (IDT), Eli Zaretskii sat on a tribble, which squeaked: >Why is that? Is it because the crashes happen after a lot of >processing? Does the crash happen predictably given some specific usage >scenario? It was long since fixed, but when it was occurring, the program: * Did some numerical computations in main(). * Tried to jump to a function pointer. * Died. Stepping might have been reasonable in this case, if I had been able to get a debugger working at all. Incidentally, the stuff I'm messing with uses, by and large, graphics. Consequently, debuggers are going to be inapplicable in a lot of cases. In fact, making them draw extra stuff to the screen under known conditions for misbehavior, or drop to text mode and execute some printf()s, has proven more fruitful. >> ISTR discussing this in connection with g++ a few months back, and the >> conclusion was that stabs debugging info was theoretically better but >> not available/broken/something else for some reason. Has this changed? > >stabs debugging is better because the compiler generates much more >detailed info, including more detailed line number information and other >important data. And the not available/broken bit? I distinctly remember it being on a wishlist somewhere, implying it existed and functioned in unix gcc but was broken/not yet implemented for DOS. >Is this the latest RHGDB? I'd suggest to get the latest versions of all >the debuggers, including GDB 5.0. The debug support in DJGPP v2.03 is >_much_ better, including support for signals, exceptions, FP code >debugging, etc. There's a lot of FP code in this stuff of mine, but it's been integer code, pointer arithmetic, and miscellaneous non-traceback-generating fatal heisenbugs that have been plaguing me. And some weird heisenbugs *in integer code that doesn't use pointers* -- stuff working and then a few hours later generating spurious results, with no change and with every i dotted and t crossed when it comes to avoiding using uninitialized data. Incidentally, one persistent annoyance has been the compiler failing to bomb if a return is omitted along some execution path in a function that's declared as returning a value. This obviously should be an error if the compiler can prove that the function can in fact fail to return a valid value for some inputs, and a warning in every other case. -- 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.