seg fault

[Bill Cunningham]

Maybe time for you to give up Bill?

On C? No

You seem to get nowhere fast.

That's for damn sure.

You

know you should provide context. What the hell do you mean "gdb says"
here? It says it when? After you have done what? On what line of code?
Did you read the tutorial I linked to you where you are specifically
shown LINE BY LINE how to examine what caused a segfault? You know, the
one by RMS you said you would read?

Yep. On windows then switched to my linux system and started to use gdb
and looks like I forgot what I read or what I thought I read. I run a dual
boot.

Bill

 

[Bill Cunningham]

Don't spoon feed him or he will never learn.

Not quite.

Teach him how to think

impossible probably.

and
work out the issue himself.

I've worked on issuses for years and not learned. Alot is because I wasn't
taught right.

Now he will probably just do a null check

and not learn anything at all and come whining back with the same issues
in about 16 hours. Learn how to use the tools to help yourself.

I say nothing beats understanding C. A debugger doesn't teach. It helps
point things out. Fprintf redirected to bash's stderr is still pretty damn
good.

Bill

 

[santosh]

Bill Cunningham wrote:

Ok here's the program.
#include <stdio.h>
#include <stdlib.h>

int
main (int argc, char *argv[])
{
FILE *fp;
double x;
if ((x = strtod (argv[1], NULL)) == '\0') /*segfault */

Oh dear. What are you doing comparing strtod's return value with a null
character?

Strtod return +/-HUGE_VAL in case of overflow and zero in case of
underflow and failure to convert for other reasons. If either overflow
or underflow has occurred errno will contain ERANGE.

So a better method of using strtod is:

#include <errno.h>
#include <stdlib.h>
#include <math.h>

int main(int argc, char **argv) {
double x;
char *endptr;
if (argc < 2) {
/* insufficient arguments */
exit(EXIT_FAILURE);
}
errno = 0;
x = strtod(argv[1], endptr);
if (errno == ERANGE) {
if (fabs(x) == HUGE_VAL) {
fprintf(stderr, "Overflow.\n");
}
else if (x == 0) {
fprintf(stderr, "Underflow.\n");
}
exit(EXIT_FAILURE);
}
else if (x == 0) {
fprintf(stderr, "Conversion failure. Stopped at %s\n", endptr);
exit(EXIT_FAILURE);
}
/* proceed */

{
puts ("strtod error");
exit (EXIT_FAILURE);
}
if (argc > 2)
{
fprintf (stderr, "usage error\n");
exit (EXIT_FAILURE);
}

As you were told previously, checking of argc must come *before* the
call to strtod.

 

[santosh]

santosh said:

Bill Cunningham wrote:

[ ... ]

I use fprintfs to stderr so there's an error only if there's an
error.

How do you come to this conclusion?

What are you suggesting, santosh - that there might be an error even
if there isn't an error?

I was asking Bill why "there's an error only if there's an error" only
when he is using fprintf.

One or more errors could have occurred before the fprintf call, perhaps
after it, perhaps in the call itself. Fprintf doesn't guarantee that
you will spot all your errors.

 

[Barry Schwarz]

I have put together this program that seems to do what I want without
error checking added yet. If I just run the program it produces a

So you actually want the program to produce a segmentation fault? What
is the problem then?

segmentation fault. If I add the proper value say 43.56 it's fine. Does

Given the number of errors in your code, that is unlikely.

anyone see what's wrong ? I have a c99 compiler. Thanks.

Which compiler are you using that you think is C99?

#include <stdio.h>
#include <stdlib.h>

int main ( int argc, char *argv[] ) {
FILE*fp;
double x;
x=strtod(argv[1],NULL);
if (argc !=2) {
fprintf(stderr,"usage error\n");
exit(EXIT_FAILURE);
}
fp=fopen( "data", "a");
ftell(fp);
fseek(fp,sizeof(double),SEEK_CUR);

You open the file for text. What do you think the sizeof(double) has
to do with anything in a text file?

fprintf(fp,"%.2f\n",x);
fclose(fp);
}

Remove del for email

 

[Barry Schwarz]

Ok here's the program.
#include <stdio.h>
#include <stdlib.h>

int
main (int argc, char *argv[])
{
FILE *fp;
double x;
if ((x = strtod (argv[1], NULL)) == '\0') /*segfault */

Why are you bothering to post? You ignored all the people who told
five hours before this message you how to fix this.

Why do you think that x being assigned a value of 0 (or 0.0 if you
prefer) is an error? It's a perfectly valid result from strtod.

{
puts ("strtod error");

Why does this error go to stdout ...

exit (EXIT_FAILURE);
}
if (argc > 2)
{
fprintf (stderr, "usage error\n");

while this one goes to stderr?

exit (EXIT_FAILURE);
}
if ((fp = fopen ("data", "a")) == NULL)
{
puts ("fopen error");
exit (EXIT_FAILURE);
}
if ((ftell (fp)) == -1)

What happens if ftell doesn't fail? You never save the value it
returns. What is the purpose of calling the function?

{
puts ("ftell error");
exit (EXIT_FAILURE);
}
if ((fseek (fp, sizeof (double), SEEK_CUR)) == -1)

At least three errors here:

fseek is not guaranteed to return -1 on error. It returns
non-zero.

You open fp for text. For a text file, the offset must be 0
or a value returned by ftell. sizeof(double) is neither. For a
non-zero offset, the origin must be SEEK_SET.

{
puts ("fseek error");
exit (EXIT_FAILURE);
}
fprintf (fp, "%.2f\n", x);
fclose (fp);
}

Remove del for email

 

[Nick Keighley]

I use fprintfs to stderr so there's an error only if there's an error. I've
tried learning gdb. I don't read debugging symbols and gdb looks very
overwhelming atleast to me. I have it in my system and looked over the docs.
I thought about putting breakpoints into my program and gave up because
things were too complicated. With the trouble I'm having with C and I want
to stay with it I think my plate's pretty full right now. But I'll look at
your sites.

you could try ddd which puts a GUI interface on gdb. Make sure you
compile
with debugging enabled (-g I think). DON'T strip symbols from the
executable.

 

[Richard Tobin]

Let me open your eyes, then. Easier than the steps you mention is to type:

gdb ./foo core
(gdb) bt

which tells you what line the segfault occurred on.

On most (in my experience) unix systems nowadays, that requires some
preparation: typically core dumps are disabled by default and you have
to use some command such as "ulimit" to enable them.

-- Richard

 

[Bartc]

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

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.

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

I also use interpreted languages a lot, and many errors are picked up
internally and reported as you might expect: error so-and-so in line
such-and-such of module X called from...

But crashes are not unheard of and I tried similar code to the above (note
this language uses NULL for empty strings, but I'm just using that to force
the error; that's a minor quirk to be fixed):

library "crtdll"
clang function puts(istring)

puts("")

And I get a crash just as I do with the C version, and the same funny
7xxxxxxx address as before. Now, how would your gdb debugger have helped me
here? It would simply have pinpointed the part in the interpreter where
calls to dll functions are made. /Any/ dll call. In general it would tell me
the line number in the interpreter which is not very useful; I need the line
number in my program.

My view is that bugs are either straightforward (like logic errors) and can
be picked up quickly, or are so horrendously complex (even forgetting about
interpreters and such) that the sort of low-level information a debugger can
tell me is a waste of time.

 

[Johannes Bauer]

This is what gdb said
$1=1
$2=0

No, it isn't. Are you purposefully trolling?

*This* is what gdb said:

joe joe [~/tmp]: gdb ./a.out
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) r
Starting program: /home/joe/tmp/a.out

Program received signal SIGSEGV, Segmentation fault.
0x00002b25ed8bdc78 in ?? () from /lib/libc.so.6
(gdb) bt
#0 0x00002b25ed8bdc78 in ?? () from /lib/libc.so.6
#1 0x0000000000400774 in main (argc=1, argv=0x7fffbd43d2b8) at x.c:7
(gdb) up
#1 0x0000000000400774 in main (argc=1, argv=0x7fffbd43d2b8) at x.c:7
7 x=strtod(argv[1],NULL);
(gdb) p argv[1]
$1 = 0x0
(gdb)

Do you know what it's saying. I can strip these executables of debugging
symbols and still get a partial symbol table. I sure would like to know
about BFDs like ELF COFF and win32/pe. Can gdb or a hexdump of the different
parts of a file show this ?

Ehrm, are you sure you want this? You don't know how to handle gdb and
want to try assembly debugging? Sure, gdb can:

(gdb) dis
Dump of assembler code from 0x2b25ed8bdc77 to 0x2b25ed8bdcb8:
0x00002b25ed8bdc77: lds (%rdi),%ecx
0x00002b25ed8bdc79: mov $0x5d,%dh
0x00002b25ed8bdc7b: add %cl,0xf(%rax)
0x00002b25ed8bdc7e: mov $0x4244f6c3,%esi
0x00002b25ed8bdc83: add %esp,(%rax)
0x00002b25ed8bdc85: jne 0x2b25ed8bdc75
0x00002b25ed8bdc87: cmp $0x2d,%bl
0x00002b25ed8bdc8a: je 0x2b25ed8be0d1
0x00002b25ed8bdc90: cmp $0x2b,%bl
0x00002b25ed8bdc93: movl $0x0,0x78(%rsp)
0x00002b25ed8bdc9b: je 0x2b25ed8be32b
0x00002b25ed8bdca1: movzbl (%r14),%esi
0x00002b25ed8bdca5: xor %edx,%edx
0x00002b25ed8bdca7: test %sil,%sil
0x00002b25ed8bdcaa: je 0x2b25ed8bdcd5
0x00002b25ed8bdcac: cmp 0x0(%rbp),%sil
0x00002b25ed8bdcb0: mov $0x1,%ecx
0x00002b25ed8bdcb5: je 0x2b25ed8bdcc9
0x00002b25ed8bdcb7: jmp 0x2b25ed8bdcdd
End of assembler dump.

Now I would sure be surprised if that would have helped you.

Regards,
Johannes

 

[Richard]

[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

Uh huh. Then in this case you were looking for the wrong thing it
appears. Did you use gcc?

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

Uh huh.

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. Now for a program that crashes:

So the tutorial showing how to do it, did it? Good.

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

How approx? What is dumppe if not a kind of debugger btw?

With dbg, I get this:

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

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.

Did you step through?

I tried the following two lines in some other code just to refute your
claims:

,----
| p = 0;
| strcpy(p,"Hello World\n");
`----

the bt gave me this:

,----
| Program received signal SIGSEGV, Segmentation fault.
| 0xb7e52825 in memcpy () from /lib/i686/cmov/libc.so.6
| (gdb) bt
| #0 0xb7e52825 in memcpy () from /lib/i686/cmov/libc.so.6
| #1 0x08048415 in main () at files.c:15
`----

Tine taken to find line of segfault was about 5 seconds from compile to
seeing the "problem".


In addition if you are unable to see how expressions for
breakpoints/watchpoints are useful then I feel I can never convince you
since they are such a useful and important part of setting traps (halt
points) for elusive bugs where you want to see the context data when
approaching crash time.

Now, when you program for twenty years or so without debugging tools you do
get quite proficient at tracing bugs,

Yes you do. But its as clear a day to me you went out of your way to
find this difficult. Nothing in life worth knowing is necessarily
"easy". I have debugged many times "without" a debugger. But to in any
way claim it is easier without one for the majority of situations where
you know what you are doing to include debug info and how to query the
debugger is, frankly, ridiculous. Maybe I just know how to use one
better than many in c.l.c. A lot here sure know ISO C better than me. But
if a program segfaults it takes about 3 seconds to find out where with
gdb. Certainly quicker than re-reading hundred of lines of code and
littering printfs around along with the potential for introducing more
bugs.

Anyway, we've been through this before. Not using a debugger is, for a
professional programmer and maintainer of code, foolish in my
opinion. Still, maybe you have C reading skills I can only dream of.

 

[Richard]

No, it isn't. Are you purposefully trolling?

There seems to be an anti debugger movement here. Someone even says
because Kernighan reckons he doesnt need one then others dont either. I
would like to talk to BK about his views on that one in the modern age.

*This* is what gdb said:

joe joe [~/tmp]: gdb ./a.out
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) r
Starting program: /home/joe/tmp/a.out

Program received signal SIGSEGV, Segmentation fault.
0x00002b25ed8bdc78 in ?? () from /lib/libc.so.6
(gdb) bt
#0 0x00002b25ed8bdc78 in ?? () from /lib/libc.so.6
#1 0x0000000000400774 in main (argc=1, argv=0x7fffbd43d2b8) at x.c:7
(gdb) up
#1 0x0000000000400774 in main (argc=1, argv=0x7fffbd43d2b8) at x.c:7
7 x=strtod(argv[1],NULL);
(gdb) p argv[1]
$1 = 0x0
(gdb)

Bartc seemed to have difficulties too getting the real output. I wonder
why this is?

 

[Joachim Schmitz]

Did Richard Stallman write the above? If so I'll try it.

It is titled "RMS's gdb Tutorial", so yes, it seems reasonable to assume
Richard Stallman wrote it.
But then again it mentions a (e-mail address removed) being the contact, which
does not realy looks like his email address.

But what does that have to do with whehter or not you try it?

Bye, Jojo

 

[Richard Tobin]

gcc -g3 -o c c.c

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

-o c make the output program be called "c". How were you compiling
it before? If you don't know that it sets the name of the program,
are you sure you are running the program you compiled?

-- Richard

 

[Bartc]

Uh huh. Then in this case you were looking for the wrong thing it
appears. Did you use gcc?

'gdb download windows'. Maybe should have added .exe or .zip.

How approx? What is dumppe if not a kind of debugger btw?

It's a disassembler. Showing function names with any luck. Sometimes I can
derive my source linenumber from examining the instructions, once I know
which function.

I tried the following two lines in some other code just to refute your
claims:

,----
`----

the bt gave me this:

I got the same as before. But this might be an old gdb (from 2002 or 3).
(Using lccwin32 however, it went wrong at an address inside my program,
perhaps due to inlining.)

Yes you do. But its as clear a day to me you went out of your way to
find this difficult.

Well I didn't try too hard. I was showing some of the problems newcomers
might experience, and why they might be reluctant to overcome the initial
hurdles.

And in my case: first of all I was using the wrong languages (no debugger).

Then in the sort of interactive applications I was working with, there were
more dominant matters: making the error repeatable for a start. Or
reproducing the error on a small dataset, like a single object (for cad)
instead of several thousand.

This all comes under techniques that would be used instead of, or in
preparation for, a product like gdb. If the error only occurs at a user's
site, then there are other methods still to be thought out. Gdb wouldn't
help here.

One big help was introducing interpreted code for much of the application.
Then if a something went wrong, the user would get an error message for that
module, which could be reported back, but the application would continue
working. (And the user could save his morning's work and not get angry

So it's not just a choice between gdb (it seems to me a low-level product
used as a last resort) and loads of printf dianostics.

Still, maybe you have C reading skills I can only dream of.

No.

 

[Bartc]

-o c make the output program be called "c". How were you compiling
it before? If you don't know that it sets the name of the program,
are you sure you are running the program you compiled?

Of course, setting the executable name. I'd forgotten also the default
output was called a.exe and had been attempting to debug the output of
another compiler.

However the debugger results, reported in my other post, are the same.

 

[Ben Bacarisse]

Bah. We've been down this road before. A good debugger with read watch
points, write watch points, expression watch points etc. can ONLY make
it easier.

Yes, we've been here before, but I think it is worth having one last
stab at explaining one of the "other" points of view. I will try to
be very clear:

First, I use debuggers. There are times when they are just the right
tool. Please don't miss-represent the following as my never using
then or my never advocating their use.

However, I don't think "they can only make it easier". That very much
depends on how your mind works. It may be true for some people -- I
can't say -- but for me it often is not. Watching code execute or
values change in a debugger takes the compact expression of an
algorithm and unwinds it over time into a sequence of trivial events.
Now, for some people, it seems that they can take that and synthesise
an understanding of the code from these events. I find that very
hard. There is too much data and it is in the wrong form -- ordered
over time.

The net effect of most programs (or program fragments) is to bring
about some state of affairs (that the data be sorted, that variable x
contain the date of Easter 2012, whatever) and these are static
properties, not temporal ones. Extracting what a program is really
doing (or not doing right) from the sequence of its steps is, for me,
very much harder than analysing its text.

My computing experience dates from the days before debuggers
(certainly before source-code debuggers) so I remember the joy having
these sophisticated tools for the first time. But I also remember
wasting a lot of time with them before I learnt that watching code
execute often[1] impeded my understanding of it. Please, before you
question my honesty or claim I must be posturing, consider the
possibility that people are different and not everyone thinks the way
you do. When you posted a while back that running code under a
debugger was an essential technique for understanding it, I did not
dismiss it. I added it to the set of thing I know about how people
think about (and work with) programs.

Finally, there are also situations where debuggers are not available.
Curiously, we are moving into a new phase where they are, to all
intents and purposes, not available -- concurrent and threaded
programming. From what I have seen so far, current debuggers can not
help (much) in understanding the behaviour of buggy concurrent
programs, unless the bug are in the non-concurrent behaviour, of
course. I am sure this will be sorted out eventually, but for now,
reasoning about your concurrent programs is the state of the art.

[This if off topic, of course. I have set followup-to
comp.programming where I would be happy to continue this debate.
Please consider honouring the followup-to, quoting all or most of my
text. I won't reply if you want to keep the discussion here.]

[1] Not always. Remember: I do use debuggers. If you include tools
like mudflap and valgrind, I use debuggers all the time.

 

[santosh]

santosh said:

santosh said:

Bill Cunningham wrote:

[ ... ]

I use fprintfs to stderr so there's an error only if there's an
error.

How do you come to this conclusion?

What are you suggesting, santosh - that there might be an error even
if there isn't an error?

I was asking Bill why "there's an error only if there's an error"
only when he is using fprintf.

One or more errors could have occurred before the fprintf call,
perhaps after it, perhaps in the call itself. Fprintf doesn't
guarantee that you will spot all your errors.

I've never heard of Fprintf - but you can't begin a sentence with a
lower case letter! Ain't the English/C boundary wonderful?

Seriously, you are obviously right - it's our job to spot bugs, and
fprintf is at best a tool that can help us to do that (just as a
debugger is only a tool). Tools are useful, but only fools rely on
them to do things they are not designed to do. We can *use* tools to
do things they are not designed to do, but if we are wise we will
recognise that they may not achieve the goal we intend.

In this case, the best approach is probably to use a debugger to find
out where the seg fault is occurring, and then apply one's brain to
find the cause. Debuggers /can/ help with this, especially good ones
that let you explore the state of the call stack (e.g. the Visual C++
debugger, or gdb), but they are no magic wand, and no substitute for a
clear head and a knowledge of the language.

I completely concur except to say that in this particular case a
debugger was not necessary because multiple cases of undefined
behaviour simply _stood_ _out_ at a first glance at the code.

 

[santosh]

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

 

[Richard]

'gdb download windows'. Maybe should have added .exe or .zip.


It's a disassembler. Showing function names with any luck. Sometimes I can
derive my source linenumber from examining the instructions, once I know
which function.


I got the same as before. But this might be an old gdb (from 2002 or 3).
(Using lccwin32 however, it went wrong at an address inside my program,
perhaps due to inlining.)



Well I didn't try too hard. I was showing some of the problems newcomers
might experience, and why they might be reluctant to overcome the initial
hurdles.

You dont have to. We all know nothing comes for free. What it really
showed, to me, was a reluctance to try to make it work for you. YOu
clearly do not know what a debugger can do for your and scoff at the
need for one. Sorry, and I dont mean this as a negative, but thats the
way it seems. If I worked with you I would be very keen to help you get
up and running with gdb or similar as it saves a lot of time and effort.

Do try the tutorial and report back.