🚀 go-pugleaf

%% Regarding Re: @@$##&%^$! gdb!!!! ARGGGGHHH!!!!!; you wrote:

    js> I think my allegations themselves are really still quite valid.

But the problem was, you didn't make any.  Except that the info pages
were "crappy" with no specific complaints except you can't get the
"simplest answer" from them... which are both quite incorrect, I think.

    js> Further, it turns out that the problem was most likely in a
    js> piece of system code (strtod) in Linux, and that this code did
    js> not have symbolic information in it, which is why I got no info.

Unless you're using very alpha copies of some libc, I *SERIOUSLY* doubt
the bug will turn out to be a problem in strtod()--that's a standard,
stable function.  I'd look again--since you're using doubles, I'd
especially look to make sure I'd included all the right header files...
But you never know I guess, could be strtod().

    js> (Now I need to find a FAQ somewhere that tells me how to link
    js> with my libg libraries instead of libc).

Usually adding your own library search path with -L or explicitly
linking your library with -l does the trick.

I'd try the Info pages for your compiler (GCC I presume) for this kind
of info.

    js> But nowhere did gdb give me that clue.  The best that I could
    js> think of at the time was going through all the libraries with
    js> 'nm'-- a delectable task, especially when, as you correctly
    js> assert, the better assumption would be that even if it were
    js> bombing out on a system call, it was because of some of 'my own'
    js> code.

Who cares where the function is, if the bug is in your own code?  You
happen to be working on a Linux system (good choice!  Love it myself) so
you have access to the source code and can rebuild the system libraries
with -g.  But don't let that distract you: most systems don't allow that
so as a general debugging procedure it's not too useful.

Go back through the stack to the last place you had control, and find
out what you're passing to whatever system function you're calling, then
try to figure out why that won't work.

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

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

Why should it say function?  Where else is it going to stop but in a
function?  It's not going to stop in the data segment, or the harddisk,
or Cleveland... :)

    >> 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.

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

There's no way GDB can give you this info.  It runs on literally tens of
systems.  There's no way that the GDB manual can describe what the
format of the system library function names for each of them is.

If the user is such a newbie that he/she doesn't realize that when you
call system functions they might call others, etc., and that if their
program stops in a function with some weird name they didn't write that
they need a stack traceback to find their code, then you're 100%
correct, the GDB manual isn't going to help.  I maintain that's not the
purpose of the GDB manual--more later.

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

That may be so, but without providing the stack trace at least, and not
mentioning you even tried to get one, there's little anyone can do
suggest solutions.

    js> Here's the output:

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

    js> See my point?

Well, that's a completely different story!  If you'd put this in your
original message we could have helped you out much more quickly.  It
looks like your stack is corrupted, and GDB can't do anything about that
(nor could any debugger: if your stack is corrupted it's gone).  If the
end of your stack trace doesn't reveal a call to "main" or "__main" or
something, then you haven't seen it all (since every program calls main
right off) and when you see the ?? that means GDB couldn't figure out
what the symbol name was... stack is bad.

You'll have to infer from how the program works (i.e., what it was doing
just before it crashed) a general idea of where the problem is occuring,
then set a breakpoint there and step through the code until you get to
the crash to figure out where it is.

Stack corruption most often occurs because you've overwritten the
boundaries of some array, or freed some memory in a bogus fashion, or
something like that.  I'd check your stack and heap usage for
overwrites.

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

Aha!  *That's* a concrete criticism someone can work with! :)  I'd
suggest bringing it up in the gnu.gdb.bugs newsgroup, and asking for
more examples in the manual.  Maybe even providing some example examples
that might have helped you.

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

Maybe so.  That's another concrete criticism someone might be able to
work with (although specific instances or even better, examples of how
it could be done better are always more useful).

I don't agree that the GDB manual is only for advanced programmers: it
goes out of its way to explain terms such as stack, frame, etc., and it
gives concrete examples of when you might want to use various commands
and what they can do.  I'm sure even a fledgling programmer could easily
understand how to do what they wanted to do using the manual.

But the thing you need to realize is that the GDB manual isn't about how
to debug programs, it's about how GDB works, and how you can use it to
debug programs.

So basically, it won't help a newcomer decide *how* to debug their
program, but once they know more or less what they want to do ("I want
to see a list of functions that have been called", "I want to examine
the contents of this variable", etc.), the manual does a good job (IMHO)
of telling them how to do it with GDB.

If you need more help with debugging methodology (and I'll be the first
to admit debugging is an art unto itself, and many good programmers are
sucky debuggers--and vice versa) there're probably other sources of
info; I don't think FSF is in the business of developing such resources.

                                                                paul
 _____________________________________________________________________________
/                                                                             \
 Paul D. Smith                   | "I'm not Gallagher, I'm the Dream Weaver."
 <psmith@wellfleet.com>          | 
 Bay Networks, Inc.              |                        -- _Robotman_
 Network Management Development  | 
\_____________________________________________________________________________/