🚀 go-pugleaf

Hi, Paul.  Thanks for your response.  While I can appreciate your
frustration with my flaming to the net like that (and admittedly, I
definitely could have cooled down before writing), I think my allegations
themselves are really still quite valid. 

Further, it turns out that the problem was most likely in a piece of
system code (strtod) in Linux, and that this code did not have symbolic
information in it, which is why I got no info.  (Now I need to find a FAQ
somewhere that tells me how to link with my libg libraries instead of
libc).  But nowhere did gdb give me that clue.  The best that I could
think of at the time was going through all the libraries with 'nm'-- a
delectable task, especially when, as you correctly assert, the better
assumption would be that even if it were bombing out on a system call, it
was because of some of 'my own' code. 

On Wed, 9 Nov 1994, Paul Smith wrote:

>     js> Program received signal 8, Floating Point Exception.
>     js> 0x112cd in _IO_dtoa ()
> 
> It did tell you.  It stopped in function _IO_dtoa(), obviously.

How is that obvious, again?  Does it say, "Stopped in *function* _IO_dtoa()"?

> Since that function begins with an underscore and has some strange name
> you probably didn't write, you can infer that some function you wrote
> called a system function or something, and eventually ended up here.

This I actually knew, but that is still not obvious if I hadn't, and there 
is no clue as to *where* newbies can find that info.

> The question you really want to ask is, what was the last function
> called that *I wrote* when this bug happened (we're assuming here that
> the bug isn't in the system libraries but rather your code--certainly
> not always the case, but a good first bet :).

That really *is* what I am asking.  Perhaps I was a bit nebulous in my 
frustration after two days of looking at this same line of code. :)

> Well, I looked at the GDB Info menu, and quickly spotted this
> likely-looking candidate:
> 
>     * Stack::                       Examining the stack

So did I.

> Huh!  Examining the stack.  Sounds like exactly what I want to do.
> Choosing that menu option revealed:
> 
>     Examining the Stack
>     *******************
> 
>        When your program has stopped, the first thing you need to know is
>     where it stopped and how it got there.
> 
> Wow, looks promising!  Looking at the menu for that we see:
> 
>     * Backtrace::                   Backtraces
> 
> And selecting that we find:
> 
>     Backtraces
>     ==========
> 
>        A backtrace is a summary of how your program got where it is.  It
>     shows one line per frame, for many frames, starting with the currently
>     executing frame (frame zero), followed by its caller (frame one), and
>     on up the stack.
> 
>     `backtrace'
>     `bt'
>          Print a backtrace of the entire stack: one line per frame for all
>          frames in the stack.
> 

Yes, I had tried a 'bt' before posting.  Although it is my fault for not 
posting that I had tried a bt.  I really didn't want to get into all the 
things that I had tried because it would take forever and I feared I 
would lose people responding if the letter were too long.

Also, there could be a few more example sessions in the info page.  
Theirs concentrates on making a breakpoint, which assumes you already 
know the general area where the problem is.

Here's the output:

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)

See my point?

> Plus much other good info.  Even without knowing what a "backtrace" is,
> there're just a couple of other menu items under "Examining the Stack"
> and this is the second one, so it shouldn't take long to get there just
> by linear progression.

Good assumption.  It was mine, too.

> All there, and not very difficult to find IMHO.  Are you sure you're
> reading the right manual?  If not, I'd work on that first.  If so,
> perhaps you just need to try a bit harder before cursing GDB or its
> documentation for info it clearly provides in a straightforward manner,
> and you just can't find.

Another good rule of thumb, already applied.

Look, once again, I have no doubt that the online documentation really
does work fine for you.  What I think you're failing to understand is that
it doesn't *for me*.  And that's because I'm not at the level of
sophistication with programming that you probably are.  The documentation
therefore organizes, indeed *structures* information in a way that would
'jive' with the head of an advanced programmer.  It does very little,
however, to organize information in a way which would answer the basic
questions of a newcomer.  (In fact, I've been programming since I was a
'tike, so I would humbly say that I'm 'intermediate', and that I'm a
newcomer to stuff like gdb and system calls, etc..).  A better newbie
section would be appropriate.. 

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