Re: seg fault

Bartc wrote:

"Richard" <rgrdev@xxxxxxxxx> wrote in message
news:g39u2m$13b$1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx

[advocating debuggers]

In this case he could use printfs etc til the cows came home and
still not have clue where the crash happened.

run
bt

I've never used a debugger, ever, but I thought I'd give this a go.
First problem was to get gdb for Windows, but 10-15 mins on google and
no luck (all those .tar.gz files I kept seeing did not look
promising). But then I found gdb.exe as part of my dev-c++ (which I
rarely use).

Then, it kept saying 'no debugging symbols found' no matter what -g3
or -ggdb switches I use for gcc. Until I tried:

gcc -g3 -o c c.c

as suggested by the tutorial (although it didn't explain what -o
filename does) which fixed that.

The -o switch instructs gcc to place it's output in a file whose name is
specified as an argument to the switch. Otherwise the output file is
named according to certain defaults. From the gcc manual:

---------
-o FILE'
Place output in file FILE. This applies regardless to whatever
sort of output is being produced, whether it be an executable file,
an object file, an assembler file or preprocessed C code.

If `-o' is not specified, the default is to put an executable file
in `a.out', the object file for `SOURCE.SUFFIX' in `SOURCE.o', its
assembler file in `SOURCE.s', a precompiled header file in
`SOURCE.SUFFIX.gch', and all preprocessed C source on standard
output.
---------

Now for a program that crashes:

#include <stdio.h>

int main(void) {
char *p=0;
puts(p);
}

Without a debugger I anyway get a report telling me at want address it
went wrong (and if that address is in my program, I can use dumppe to
find the approximate place -- this is for Windows).

With dbg, I get this:

(gdb) bt
#0 0x77c41908 in _end__ ()
Cannot access memory at address 0x406000

My session is:

$ gdb ./a.out
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db
library "/lib/tls/i686/cmov/libthread_db.so.1".

(gdb) run
Starting program: /home/santosh/tmp/a.out

Program received signal SIGSEGV, Segmentation fault.
0xb7e432a3 in strlen () from /lib/tls/i686/cmov/libc.so.6
(gdb) where
#0 0xb7e432a3 in strlen () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7e2e9bc in puts () from /lib/tls/i686/cmov/libc.so.6
#2 0x08048383 in main () at 2.c:5
(gdb)

So gdb clearly indicates where the fault occurred - in the strlen
function, which was called from puts, which was called from line five
in the main function.

Which is not that that much more enlightening. What I want is "called
from line 5 in c.c", which I suppose you will tell /is/ possible with
more intensive study of gdb.

GDB is actually a very powerful debugger, but I'll admit that it is a
steep learning curve at first.

More importantly, to a beginner in programming, a the virtues of a good
debugger are not immediately apparent, rather like how the virtues of a
seat-belt are not immediately apparent to youngsters. One has to "stick
with it" for a certain amount of time (during which things can be
frustrating and the results obscure) before the benefits start becoming
apparent.

It's easier and more natural for a beginner to insert printfs and read
the source code, and this is a good method too, very effective under
most situations. And unfortunately GDB was never meant for a beginner
or the faint-hearted. But there are times when the flexibility offered
by a debugger makes it easier to locate the bug than static analysis
and information from debugging printfs.

Now, when you program for twenty years or so without debugging tools
you do get quite proficient at tracing bugs, and there's a few other
techniques than using printfs or equivalents (in my case, I was using
assembly, and homemade languages, where there /was/ no debugger and
where bugs could be due also to errors in the compiler, or to errors
in the compiler than compiled the compiler, etc.)

You could use GDB with any compiled program debug through the machine
language instructions. For Linux ALD is specifically suited for this
purpose.

<snip>

.

Relevant Pages

  • Re: function pointers
    ... I am using gcc under ... gdb, and the compiler, exactly like in 1986 when I first started using ... when running on linux, I usually use gedit or kedit. ... There is only one debugger: ...
    (comp.lang.c)
  • [PATCH 04/37] Separate the gdbstub from the debug core
    ... kernel debugger exception logic and to the gdbstub.c which contains ... the logic for allowing gdb to talk to the debug core. ... -static int write_mem_msg ...
    (Linux-Kernel)
  • using gdb on windows
    ... I googled for "gfortran debugger" and found a lot of information that was ... I believe they are available for linux. ... GCC (the GNU Compiler Collection). ...
    (comp.lang.fortran)
  • Re: LPC213x IDE
    ... I'd need a debugger too I guess? ... When I say "gcc" I'm really referring to the complete GNU toolchain, ... comprising GNU make, gas assembler, gcc compiler, ld linker, gdb ... If you require graphical frippery, ...
    (comp.arch.embedded)
  • Re: seg fault
    ... I've never used a debugger, ever, but I thought I'd give this a go. ... First problem was to get gdb for Windows, but 10-15 mins on google and ... or -ggdb switches I use for gcc. ... The -o switch instructs gcc to place it's output in a file whose name is ...
    (comp.lang.c)