seg fault

[Richard]

[Followup retained, but I've crossposted this reply back to comp.lang.c,
and set followups to comp.programming]

Ben Bacarisse said:

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 don't. You're trying to explain the blindingly obvious to a *troll*. He
isn't ever going to get it, because he doesn't *want* to get it. He has
two fixed and incorrect ideas on this subject: (a) he thinks that
debugging without a debugger is impossible, and (b) when people say they
rarely use a debugger, he interprets "rarely" as "never".

Nonsense. As usual you twist things and lie.

My position is that a debugger makes life a LOT easier in many, many
cases. I also detect from the responses here that there are many
programmer who have never used one more out of not being aware of their
facilities.

NOT recommending a debugger to someone who is having trouble finding
segfaults is bordering on insanity. Sometimes I wonder from your bitchy,
pompous posts here if that might not be nearer the truth at times.

 

[Richard]

santosh said:

Richard Heathfield wrote:

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.

Would people stop stating this? OF COURSE some errors "simply stand
out". But *even* in those cases it does no harm to use one. Sheesh.

 

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

Exactly. And ANYONE (including that preening fool Heathfield) that
disagrees that this is GOOD to help beginners like Bill find their
problems need their perspective readjusting.

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

I wont. Its as easy as anything I ever used to get going and to use the
BASIC stuff like step and breakpoints.

The only difficulty is removing ones blinkers and trying. These things
were developed by leading coders (like RMS) for a damn good reason. And
all the smart alecs in c.l.c and the rest of the world is not going to
change that.

Some points:

1) It takes hardly any more time to compile and link with debug symbols
2) running the program under the debugger takes virtually no more time
3) the benefits of catching any segfaults and INSTANTLY seeing where is
a major positive.
4) In more complicated instances (which it seems a lot of c.l.c members
have no expereince of) the ability to "trap" bugs through a mixture of
watch points and break points is indispensable.

In other posts I have also extolled the benefits of following the FLOW
of a program by stepping though the code. It is easy to see the data
change and you get a feel for the workings of a program which one simply
can not get from reading the code in virtually all cases I have
experienced.

 

[Antoninus Twink]

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.

In addition, there's a good chance that the core dump will be called
core.PID rather than just core.

 

[Bartc]

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

My gdb was 5.2.1. I now have 6.6 which is reporting line numbers in my
source as you said I should have expected.

You know, this may actually be useful sometimes! Easier than messing with
dumppe and pedump anyway.

The 6.6 (Windows gdb.zip) was from here:

http://www.engr.mun.ca/~mpbl/content/courses/2420/how-to/install/Install-on-XP.htm

In Install GDB about 1/5 down the page (the link at the top is broken).

 

[Serve Lau]

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.


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.

I always loved the VisualC++ and borland's debugger, helped find loads of
bugs fast....but then I started working on a platform that didnt have one. I
just had to use printf's. I hated it, it was so frustrating with that cycle
of adding printf, compile, start up machine, go to the spot where things go
wrong, analyze the output only to find out you needed to watch another
variable. Pretty tiresome at the end of the day. But you know, you learn and
get better at it. You start adding more and more printf's at once even at
points where you dont expect things go wrong and you add all the variables
at once. Then it gets better and you find the bugs faster.
Also, after working on the same kind of code for a few years you get so into
it that every time something goes wrong you have a hunch what it is
immediately. I'm guessing thats where the opinion comes from from some of
the guys here saying debuggers arent needed. They've been glued to the same
chair for years and know the code they work on very well. Then indeed no
more need for a debugger. Or maybe most of the code is written by themselves
too. That seems to help a lot too on the problem solving part. But if you
are new to some pieces of software and there's a crash nothing beats a
debugger. You learn the structure of the code while solving problems and
being productive, its great.

 

[Serve Lau]

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

yeah you didnt learn cos they are such bad teachers. lol

 

[Bill Cunningham]

Which compiler are you using that you think is C99?

gcc-3.4.6

 

[Joachim Schmitz]

gcc-3.4.6

And you are aware that gcc (no matter what version) is not a fully
conforming C99 compiler?
Not even with --std=c99.

Bye, Jojo

 

[Bill Cunningham]

And you are aware that gcc (no matter what version) is not a fully
conforming C99 compiler?
Not even with --std=c99.

No I didn't know that. I guess you learn something new everyday.

Bill

 

[Bill Cunningham]

Just a bunch of jumping comparing values of segment registers. Extended
stack pointer so on. Looks like garbage or should I say assembly code.

Bill

 

[jacob navia]

No I didn't know that. I guess you learn something new everyday.

Bill

The problems with gcc's implementation are completely MINIMAL.

What you also do not know is that the "regulars" in this group have been
waging a campaign against standard C because they would like to
return to C89 or maybe even further back.

When anyone speaks about standard C they will point out that
there are no implementations (what is obviously a lie) or
other half truths. "Joachim Schmmitz" is a good example.

 

[Nick Keighley]

Richard Heathfield wrote:

santosh said:
Richard Heathfield wrote:
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.

Would people stop stating this? OF COURSE some errors "simply stand
out". But *even* in those cases it does no harm to use one. Sheesh.- Hide quoted text -

ok this is boring. I suspect people are ignoring your THE DEBUGGEr IS
KING stuff
because we've heard it before. But this is once (n?) too many.

- debuggers are useful
- for the record, I sometimes use a debugger
- not everyone finds single stepping throgh code useful
- there are other ways of debugging code

and in this case I can quite understand it is possible to debug the
program
in question without a debugger. Though Bill probably needs one. The
Undefined
Behaviour probaly dosn't leap out at him.

 

[Nick Keighley]

you don't appear to

The problems with gcc's implementation are completely MINIMAL.

so you agree, gcc isn't a full C99 implementation?

What you also do not know is that the "regulars" in this group have been
waging a campaign against standard C because they would like to
return to C89 or maybe even further back.

do you have any evidence for this extraordinary statement?

When anyone speaks about standard C they will point out that
there are no implementations (what is obviously a lie) or
other half truths. "Joachim Schmmitz" is a good example.

"obviously a lie". I think yours is the obvious lie. Who said
there are no C99 implementations? I think there are about 2. Maybe 3.
win-lcc and gcc are not amongst them.

 

[Joachim Schmitz]

The problems with gcc's implementation are completely MINIMAL.

The list of problems is several pages long, I wouldn't call that minimal.

What you also do not know is that the "regulars" in this group have
been waging a campaign against standard C because they would like to
return to C89 or maybe even further back. Nonsense!

When anyone speaks about standard C they will point out that
there are no implementations (what is obviously a lie) or
other half truths. "Joachim Schmmitz" is a good example.

So you're calling me a liar? And misspelling my name?

I know that there are a few fully conforming C99 compiler and have never
claimed otherwise.
The vast majority of compilers though (in numbers of implementations as well
as in number of installations), does not. gcc, M$ Visual C, not even
win-lcc, as reported here in CLC several times.
gcc and Visual C don't even claim to be C99 conforming.

Bye, Jojo

 

[Joachim Schmitz]

Visual-C doesn't make any claim past C90/95.

I haven't said otherwise, have I?

Bye, Jojo

 

[Keith Thompson]

when people say they
rarely use a debugger, he interprets "rarely" as "never".

Nonsense. As usual you twist things and lie.
[...]
I also detect from the responses here that there are many
programmer who have never used one more out of not being aware of their ^^^^^
facilities.

[...]

Quoted without further comment.