Mail Archives: djgpp/2001/06/25/22:30:07
On Mon, 25 Jun 2001 16:10:13 +0300 (IDT), Eli Zaretskii
<eliz AT is DOT elta DOT co DOT il> 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.
- Raw text -