seg fault

[Bill Cunningham]

And with Bill's attention span god knows that he will mess up when he
keeps re-editing the code to add and remove printfs.

Concentration. Try 1 mg Klonopin 3x a day for several years. If you know
where your driving to good for you. The my head is the best debuggers we
better get ready to lose the planet.

Bill

 

[Richard Tobin]

Using a debugger is a lot easier than sprinkling prints around,
recompiling etc.

[/QUOTE]

Like I said, I've tried. I've tried all those so-called tutorials.

There seems to be a cult associated with C debuggers, much like the cult
associated with this newsgroup. The "It was hard for me; it should be
hard for you" cult.

Some people find it easier to use debuggers, some to use other
methods. But when a program gets a segmentation fault, it's hard to
see what could be easier as the first step than running it under a
debugger (typically you just type "run" followed by the arguments
you want) and looking to see where the error occurred (typically
by typing "where"). Looking at the value of variables involved in
the line in question is also trivial ("print x", for example).

Often at this point the error becomes obvious, and even if you do
nothing else with the debugger you've probably got your money's worth.

-- Richard

 

[Bill Cunningham]

(e-mail address removed)

Hmm. I am surprised. How hard can it be to do something like "step to
next line of code" and examine the local variables?

Or to type "backtrace" when their is a seg fault?

It's this easy:

http://www.unknownroad.com/rtfm/gdbtut/gdbsegfault.html

Still, if you think it doesn't help you then all to their own.

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

Bill

 

[Bill Cunningham]

Try typing 'help' at the GDB prompt.

GDB has often been accused of excessive verbosity, but this accusation
is the first I'm seeing.

That's when all hell breaks lose. When you type help you get a list of
commands that you need to type help 'command' to and get a sparse
desciption. Been there and don't want to go back.

Bill

 

[santosh]

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

Stallman will pleased to hear this.

 

[Richard]

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

Bill

Try clicking on it and using your brain for a change. But the best
advice I can offer you is to give up. You'll never crack it. Prove me
wrong.

 

[Richard]

That's when all hell breaks lose. When you type help you get a list of
commands that you need to type help 'command' to and get a sparse
desciption. Been there and don't want to go back.

Bill

Which is why you read the tutorial which introduces it bit by bit. Duh.

 

[santosh]

[ ... ]

That's when all hell breaks lose. When you type help you get a
list of commands that you need to type help 'command' to and get a
sparse desciption. Been there and don't want to go back.

Then try 'info gdb' at the command prompt.

 

[Richard]

[ ... ]

That's when all hell breaks lose. When you type help you get a
list of commands that you need to type help 'command' to and get a
sparse desciption. Been there and don't want to go back.

Then try 'info gdb' at the command prompt.

Santosh, why on earth would you recommend him the info pages? he has
already stated that he can't cope with them. They are way too
complicated for him. There are oodles of simple tutorials that would
much better suit his abilities at this stage.

 

[santosh]

Try typing 'help' at the GDB prompt.

[ ... ]

That's when all hell breaks lose. When you type help you get a
list of commands that you need to type help 'command' to and get
a sparse desciption. Been there and don't want to go back.

Then try 'info gdb' at the command prompt.

Santosh, why on earth would you recommend him the info pages? he has
already stated that he can't cope with them. They are way too
complicated for him. There are oodles of simple tutorials that would
much better suit his abilities at this stage.

Oh, I must have missed his statement of inability to follow GDB's info
documentation. He did say that he got nothing useful from 'man gdb',
but that's expected, as the man page is just a synopsis of GDB's
options and commands. The info page is a full-fledged tutorial and
manual, coauthored by Stallman. At least, that was my introduction to
GDB, and I found (and still find) it easy and useful.

But maybe he should try a tutorial with a gentler learning curve. The
one hosted at dirac.org seems appropriate.

 

[Lew Pitcher]

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
segmentation fault. If I add the proper value say 43.56 it's fine. Does
anyone see what's wrong ? I have a c99 compiler. Thanks.

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

int main ( int argc, char *argv[] ) {
FILE*fp;
double x;
x=strtod(argv[1],NULL);

If argc is 1 this passes a null pointer to strtod, which could well cause
a segfault.

Agreed.
I would recommend that the OP move the strtod() call to a point after the
argc test below...

At this point, argv[1] is guaranteed to be a non-null pointer. So, the op's
strtod() code should work properly here.


This fopen() opens the file for appending only. That means, "open or create
text ï¬le for writing at end-of-ï¬le"

You also need to check fp for nullness here.
Agreed.

Now, what is the above ftell() doing here? You (the OP) don't store the
results anywhere, and there are no usefull side-effects with ftell()

Hmmmm.... According to the standards,
"Opening a ï¬le with append mode ('a' as the ï¬rst character in the mode
argument) causes all subsequent writes to the ï¬le to be forced to the
then current end-of-ï¬le, regardless of intervening calls to the fseek
function."
and
"For a text stream, either offset shall be zero, or offset shall be a
value returned by an earlier successful call to the ftell function on a
stream associated with the same ï¬le and whence shall be SEEK_SET."

I'm afraid that this call won't reposition the "active position" in the file
for the next write (the fprintf() below). Not only does append mode negate
the fseek() call, but the whence value (SEEK_CUR) is not legal for the
(implied) file type (text, in the absence of a "b" mode character on the
fopen() call). Finally, /if/ this fseek worked, it wouold leave a
double-sized hole in the file (that being the movement implied by the
sizeof(double) against SEEK_CUR). Text files are rarely (never, in my
memory) sparse files; I'm not sure what that hole would do to subsequent
processing.

While I realize that, under C99, the 'falling off the edge' of the main()
function involves an implicit return of a value of 0 (which is the
equivalent termination status to EXIT_SUCCESS), it would be good to
a) check the results of the fclose(fp) call, and provide an explicit
EXIT_FAILURE if the file doesn't close properly, and
b) provide an explicit return of EXIT_SUCCESS otherwise
considering that you (the OP) have already used an explicit return of
EXIT_FAILURE in part of the logic above. Consistency is good.

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[Bill Cunningham]

Your gdb says the segment fault I it's telling everything is in strtod
or strtod_internal.

Bill

 

[Bill Cunningham]

This may be where it is. Just running the program argv[0] would be
execution, giving no arguments like I didn't would be NULL.

"may be"? Say do you think debugging C-programs is like guessing where the
fault could occur? Why don't you use a helper tool, say, uhmm, a debugger?

With a program that short however you could well have inserted some
fprintf(stderr, "xyz\n") statements after every line and found it
yourself.

Regards,
Johannes

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

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 ?

Bill

 

[Bill Cunningham]

[snip]

A few minutes with Splint or PC-Lint and a C book can tell you exactly
what is wrong.
It will also behoove you to learn how to use a debugger. It is a very
bad idea to try to program by the seat of your pants (meaning making
*guesses* about what various program constructs are supposed to be
doing). If you learn the correct meanings of the language constructs
and also how to use tools at your disposal then you can learn to be an
effective programmer. If you do not learn these things then you will
never learn to be an effective programmer. It is not difficult to do
it, though it can be a bit tedious.

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 */
{
puts ("strtod error");
exit (EXIT_FAILURE);
}
if (argc > 2)
{
fprintf (stderr, "usage error\n");
exit (EXIT_FAILURE);
}
if ((fp = fopen ("data", "a")) == NULL)
{
puts ("fopen error");
exit (EXIT_FAILURE);
}
if ((ftell (fp)) == -1)
{
puts ("ftell error");
exit (EXIT_FAILURE);
}
if ((fseek (fp, sizeof (double), SEEK_CUR)) == -1)
{
puts ("fseek error");
exit (EXIT_FAILURE);
}
fprintf (fp, "%.2f\n", x);
fclose (fp);
}

gdb says

$1=1
$2=0

Bill

 

[Richard]

Your gdb says the segment fault I it's telling everything is in strtod
or strtod_internal.

Bill

So there's your answer. The reason is obviously trivial.

 

[Richard]

This may be where it is. Just running the program argv[0] would be
execution, giving no arguments like I didn't would be NULL.

"may be"? Say do you think debugging C-programs is like guessing where the
fault could occur? Why don't you use a helper tool, say, uhmm, a debugger?

With a program that short however you could well have inserted some
fprintf(stderr, "xyz\n") statements after every line and found it
yourself.

Regards,
Johannes

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

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 ?

Bill

Try learning the very basics before bandying around big words.

 

[Richard]

[snip]

A few minutes with Splint or PC-Lint and a C book can tell you exactly
what is wrong.
It will also behoove you to learn how to use a debugger. It is a very
bad idea to try to program by the seat of your pants (meaning making
*guesses* about what various program constructs are supposed to be
doing). If you learn the correct meanings of the language constructs
and also how to use tools at your disposal then you can learn to be an
effective programmer. If you do not learn these things then you will
never learn to be an effective programmer. It is not difficult to do
it, though it can be a bit tedious.

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 */
{
puts ("strtod error");
exit (EXIT_FAILURE);
}
if (argc > 2)
{
fprintf (stderr, "usage error\n");
exit (EXIT_FAILURE);
}
if ((fp = fopen ("data", "a")) == NULL)
{
puts ("fopen error");
exit (EXIT_FAILURE);
}
if ((ftell (fp)) == -1)
{
puts ("ftell error");
exit (EXIT_FAILURE);
}
if ((fseek (fp, sizeof (double), SEEK_CUR)) == -1)
{
puts ("fseek error");
exit (EXIT_FAILURE);
}
fprintf (fp, "%.2f\n", x);
fclose (fp);
}

gdb says

$1=1
$2=0

Bill

Maybe time for you to give up Bill? You seem to get nowhere fast. 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?

 

[santosh]

Your gdb says the segment fault I it's telling everything is in
strtod or strtod_internal.

Yes. Make sure that you pass strtod a pointer that actually points to
the string to be converted.

 

[Richard]

Yes. Make sure that you pass strtod a pointer that actually points to
the string to be converted.

Don't spoon feed him or he will never learn. Teach him how to think and
work out the issue himself. 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.

 

[Richard]

Richard Tobin said:


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. From there, it's
normally pretty easy to find out what went wrong.

Note that "normally" != "always".

Those who advocate debugger programs are doing a fine thing. Those who
advocate debugging without such a program are also doing a fine
thing.

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. Unless there is some issue with the debugger corrupting the
system of course. Never seen it myself.

Those who advocate using the right tool at the right time, the tool that
does the job *for you*, are doing an even finer thing. But those who
advocate mindless adherence to one view or the other could do the world a
favour by becoming politicians instead of programmers.

There are clearly always times where different approaches are
needed. However to give EQUAL weighting to all approaches is silly in
the extreme.

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

run
bt

could not be easier. Even for a beginner like Bill.

And being smart and suggesting there are "equally as good" ways for
something as basic as this is merely showboating and unlikely to help
him learn another tool to get the job done in a timely fashion.

Sometimes beginner should not be shown too many paths - they get
confused and take the wrong one for them. In this case, and at his
level, only a fool would not recommend using a debugger to help him on
his way.