🚀 go-pugleaf

Hello, all.  

Well, thank you all for your wonderful suggestions for my problems
with gdb.  Here's 1) a summary of the answers, and 2) how I finally fixed
the problem.  I now have a great hpgl2ps program (fourth
"enhancement"/fix) of the original from Don McCormick.  I've ported it
to Mips, MS-DOS, Linux, and hopefully, Sun.  This program converts
Hewlett Packard Graphics Language (hpgl, for plotters) files to
PostScript, for printing out.

Please pardon me for using initials for your names, but it will be
shorter to write and read.  Here is everyone who responded.  I hope I
got everyone's mail address correct:

Martin Ameskamp <ma@informatik.uni-kiel.d400.de>
John Jencek <jjencek@ind.tansu.com.au>
Jeff Law <law@snake.cs.utah.edu>
Bryan Martin <bmartin@maeroot.eng.uci.edu>
Jeremy Nelson <nelson@cs.uwp.edu>
Dan Saunders <saund921@cs.uidaho.edu>
Paul Smith <psmith@wellfleet.com>
Bob Stine <stine@axent.com>
Martin Tews <tews@cs.uni_sb.de>

BM and MT suggested that Floating Point Exceptions happen whenever the
processor is asked to do something stupid, like divide by zero, or
take the square root of -1.

BM, JN, and JJ suggested using "where"

MT suggested using "info stack".

JN suggested using "info locals", "info args", "frame X", or "print".

BS suggested using "up" a few times.

JL, MA, and PS suggested using "bt".

MA, JN, BS, and PS suggested that I compile with the "-g" option.
Actually, I had done this, but had not specified this in my original
post.

DS suggested that he and others had discovered a bug in the libc
"strtod" function where if called too many times, it will crash.  He
suggested linking with "-ieee".  This worked, and is what got the
program to work for the first time for me on linux.

I did correspond a couple of times with PS via email, and, although I 
perceived him to be a tad condescending, he did make 2 excellent points.

First, he suggested that I had not really provided enough information
about what I had already tried.  When I provided him with a few
attempted commands: 

Program received Signal 8, Floating Point Exception
0x112cd in  _IO_dtoa ()
(gdb) bt
#0 0x112cd in _IO_dtoa ()
#1 0x6 in ?? ()
(gdb) where
#0 0x112cd in _IO_dtoa ()
#1 0x6 in ?? ()
(gdb) info stack
#0 0x112cd in _IO_dtoa ()
#1 0x6 in ?? ()
(gdb)

he suggested that the stack had been corrupted, and that I would have
to go back to the program and infer from a a general idea of how the
program works an idea of where to go and then set a break point and
step through.  Since this is someone else's code originally, and has
many modules, it was what I was originally trying to avoid by using gdb
in the first place.  DS also suggested that I check the heap and stack
usage for overwrites, since these usually happen because of
overwriting the boundaries of some array. I don't really know how to
do this, but I can learn.

Second, PS suggested that I had not made concrete suggestions for how
the gdb documentation could be improved.

The problem with the gdb documentation (both info and man pages) is
that it is structured to answer the kinds of specific questions about
gdb that pertain more to how to use gdb to get what you want out of
it.  But this documentation does not (with the exception of a single
example using breakpoints and steps which was useless for me at the
time) include *strategies* for debugging.

According to DS, I ought to go to the bookstore and find a book or two
on it, or go back to the university and take a course or two in
programming.  While these are good suggestions, 1) I have been to several
bookstores (including technical) and not found a good source on
debugging strategies, and 2) I have a degree in computer science [and
have been programming since I was a 'tike.]

What is interesting is that I *remember* that in one of our courses in
computer science in college, they provided us with a debugging
strategies handout.  Apparently, the department had decided that there
was no good source on overall strategies for debugging, and had
written its own handout (actually about 30 pages), describing when and
where to do what and why.  It turns out they used gdb in their
examples.  Not recognizing the significance of this little gem, I
threw it away, and kept everything else, including useless notes on COBOL.

Taking PS's advice in hand, I think I could post to gnu.gdb.bugs
the suggestion that either 1) such an intro section for overall
strategies for debugging [with copious examples for each type of
situation] be added to the info pages, or 2) a *source* or sources for
overall debugging strategies be referenced from the main menu of the
info pages or at bottom of man page.  We all know how extremely
frustrating it is to hit a dead end and have no where to turn for more
information.  If anyone make suggestions for such a source, I will
compile all answers and forward to gnu.gdb.bugs and/or FSF. If there
are sources (which, like my alma mater's, which I'm checking into)
might be includable in the info pages themselves, that would be
especially helpful.

Ironically, in the end, it was not gdb which helped, but DS's
suggestion to link with "ieee" and then my own decision to just "go
for it" and try compiling the program with "gcc -Wall -ansi -pedantic"
and fix every warning, so that it compiled neatly.  This done, the
program now runs on linux, even without having to link with the "ieee"
library. 

As it turns out, several of the warnings suggested problems with
casts, and one place which printed an error statement which depended
on a variable being initialized.  But this error statement was inside
an "else" and the variable was initialized in the "if".

While DS and others still could be very right about the bug with
strtod() being called repeatedly and then crashing, I would guess that
it was originally PS who was correct about the overwrites, and that
compiling with -Wall, and going through and meticulously removing
every warning by figuring out the code fixed these overwrites.  It was
most likely the implicit casts to pointers, some of which pointed to
files, which caused the overwrites.

As an added benefit of compiling with -Wall, the postscript file
output that a mips or dos or linux produces is virtually identical
(within a few characters because of rounding of decimal places, or
because of ^M's in DOS).  And an additional bug in the program when
running on mips machines under ultrix of producing extra large (and
increasingly larger, with every label) fonts is gone.

-- 
Jeff Stern <jstern@eclectic.ss.uci.edu>