clipka escreveu:
> nemesis <nam### [at] gmailcom> wrote:
>> Hah, so that's why you either don't know about gdb or don't want to use
>> it for debugging... ;)
> 
> I have, basically, not the slightest idea about how to debug on Linux. I just
> picture that, judging from popular Linux-jockey tools like vi and such, it
> might be VERY far from trivial to get going... something like good old DOS
> "debug" comes to my mind - me no want ;)

gdb:  gnu debugger. :)  It's the standard C/C++ debugging tool in Linux 
land, or at least used to be.

It's a command-line tool, as you guessed, but fear not:  Visual Studio 
too uses several command-line tools as backend and so can you by 
downloading an IDE such as KDevelop or perhaps Eclipse with the C/C++ 
plugin.  They integrate (or hide) gdb as well as gcc under a pretty 
graphical face.

Still, man gdb, man! :D

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> It's a command-line tool, as you guessed, but fear not:  Visual Studio
> too uses several command-line tools as backend and so can you by
> downloading an IDE such as KDevelop or perhaps Eclipse with the C/C++
> plugin.  They integrate (or hide) gdb as well as gcc under a pretty
> graphical face.

Don't really want to, either, although for slightly different reasons: I'm
pretty familiar with Visual Studio, and - just like Thomas - I'm not too keen
on having to familiarize with too many tools at the same time.

Thanks anyway for the info.

Post a reply to this message

clipka <nomail@nomail> wrote:
> I have, basically, not the slightest idea about how to debug on Linux. I just
> picture that, judging from popular Linux-jockey tools like vi and such, it
> might be VERY far from trivial to get going... something like good old DOS
> "debug" comes to my mind - me no want ;)

  While gdb doesn't have a fancy GUI, it supports most of the same things
that eg. the Visual Studio debugger does. Granted, you'll have to write
commands rather than being able to click with the mouse, but this is a
tool which has been designed with the same principles as the whole gcc
suite (and the whole linux/posix/unix world).

  The most common, and also easiest, task for which gdb is very handy is
determining the exact point where a program crashes. You do it like this:

1) Compile your program with debug info (-g) and without optimizations.

2) Start gdb with your program, ie. like "gdb ./myprogram"

3) Run the program with the "run" command. (If the program takes any
   command-line parameters, you can write them after the "run".) Run it
   so that it crashes, obviously.

4) gdb will report the exact line where it crashed. The most useful thing
   to do now is to write "bt" (shorthand for "backtrace"), which will print
   the entire function call chain up to the point of the crash, with the
   line numbers of each function call. (This is especially useful if the
   program is crashing inside a library and you want to see where it's
   being called from.)

5) If needed, you can print the values of variables in scope with the
   "print" command.

  You can, of course, also add breakpoints and advance the program step
by step, but those are a bit more advanced topics.

  Note how points 4) and 5) are actually identical to what the VS debugger
will show you. The only difference is that you have to write a few commands
to get them, because there's no GUI.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> 4) gdb will report the exact line where it crashed. The most useful thing
>    to do now is to write "bt" (shorthand for "backtrace")
> 
> 5) If needed, you can print the values of variables in scope with the
>    "print" command.

Does it work for C++ also the same way? Or just C?  As in, does the -g give 
it enough information to unmunge the global names and walk the stack in 
spite of inline functions and such?  Just curious.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   The most common, and also easiest, task for which gdb is very handy is
> determining the exact point where a program crashes. You do it like this:
> ...

I'll give it a try next time I have a segfault or other crash to track down - I
guess it will be faster that valgrind for that job :)

Unfortunately, with debug information and no optimizations I don't see any crash
(still hoping for something to pop up in valgrind during cleanup though; we're
at 89% right now). But with a little luck it's the optimizations that make the
error surface, not the absence of debug info, so there is still hope that it
might get me somewhere.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Does it work for C++ also the same way? Or just C?  As in, does the -g give
> it enough information to unmunge the global names and walk the stack in
> spite of inline functions and such?  Just curious.

"You can use GDB to debug programs written in C, C++, and Modula-2."
(gdb man page)

I take that for a "yes" on your questions.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > 4) gdb will report the exact line where it crashed. The most useful thing
> >    to do now is to write "bt" (shorthand for "backtrace")
> > 
> > 5) If needed, you can print the values of variables in scope with the
> >    "print" command.

> Does it work for C++ also the same way? Or just C?  As in, does the -g give 
> it enough information to unmunge the global names and walk the stack in 
> spite of inline functions and such?  Just curious.

  Yes, gdb fully supports C++ (including eg. template expressions).

-- 
                                                          - Warp

Post a reply to this message

clipka <nomail@nomail> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> >   The most common, and also easiest, task for which gdb is very handy is
> > determining the exact point where a program crashes. You do it like this:
> > ...

> I'll give it a try next time I have a segfault or other crash to track down - I
> guess it will be faster that valgrind for that job :)

  Have you ever wondered what the 'core' file is used for (ie. have you
ever wondered what the "core dumped" is all about)?

  If you have your shell configured to dump core when a program crashes,
you can use the 'core' file in conjunction with gdb to do what I described
without having to run the program again. This can be useful if the program
crashing happens only randomly or it takes a very long time to happen.

  I must admit, though, that I don't remember now how exactly the 'core'
file was used. It might have been that gdb automatically reads it if it
exists in the current directory (and has been produced by the program in
question, an information which is most probably included in the 'core' file
itself). So in effect if you have the 'core' file from the program crash,
you can skip the "run the program from gdb" part.

> Unfortunately, with debug information and no optimizations I don't see any crash
> (still hoping for something to pop up in valgrind during cleanup though; we're
> at 89% right now). But with a little luck it's the optimizations that make the
> error surface, not the absence of debug info, so there is still hope that it
> might get me somewhere.

  You can try with optimizations and hope they still allow you to find
the location of the crash. Start with -O1 and try making it crash. Increase
from there if it doesn't seem to happen.

  gdb will still report the location of the crash, but as I said, it might
be confused by the optimizations performed by the compiler (eg. because of
the compiler moving code around or inlining functions).

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   Have you ever wondered what the 'core' file is used for (ie. have you
> ever wondered what the "core dumped" is all about)?

Well, I *know* what it is all about - actually, years ago I did some Unix
training on a HP-UX machine, and it kept "core dumping" on my self-written C
programs, which I found annoying back then because it kept cluttering my
directories with coredumps ;)

.... these days I wished why my Linux system did coredump ;)

>   If you have your shell configured to dump core when a program crashes,
> you can use the 'core' file in conjunction with gdb to do what I described
> without having to run the program again. This can be useful if the program
> crashing happens only randomly or it takes a very long time to happen.

Hey, tell me - tell me! How do I activate that? (*bouncing up and down
impatiently*)

>   I must admit, though, that I don't remember now how exactly the 'core'
> file was used. It might have been that gdb automatically reads it if it
> exists in the current directory (and has been produced by the program in
> question, an information which is most probably included in the 'core' file
> itself). So in effect if you have the 'core' file from the program crash,
> you can skip the "run the program from gdb" part.

No, I just had a look at the gdb man page: Yo have to run gdb with both the
program name and the coredump name as parameters.

>   You can try with optimizations and hope they still allow you to find
> the location of the crash. Start with -O1 and try making it crash. Increase
> from there if it doesn't seem to happen.

I just tried with full optimizations, but to no avail. The segfault seems to be
very sensitive about any changes to the binary.

Still a bit of hope: Turning on debug information in the ./configure script not
only adds symbol info to the binary, but also turns on some additional code
intended to help with debugging. Maybe if I can just get the symbol info...


Darn! Right now the code refuses to segfault at all, even with the settings that
previously killed it reproducably... Looks like I just need to wait until some
other code changes make it segfault again...

I guess I'll activate debug stuff by default from now on. And please tell me how
to activate coredumping...

Post a reply to this message

clipka wrote:
> I guess I'll activate debug stuff by default from now on. And please tell me how
> to activate coredumping...

FWIW, it used to be simply setting an appropriate ulimit.


http://www.usenet-forums.com/linux-general/96843-set-ulimit-c.html
has some interesting chatter about it that implies this is still the case.


-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message