What is a stack frame?

[Richard Heathfield]

Richard said:

A debugger is an intrinsic part of finding a deep rooted bug swiftly and
economically. It's why this exist.

I disagree that it's intrinsic. Some people may well find it so, and that's
fine. A debugger is not a crutch of which to be ashamed, but a tool that
some people find invaluable and others less so. For my own part, I
generally find it most useful as an astoundingly fast way to analyse a
core dump.

On what kind of code base? What size? How many contributors? How long
had you worked on that code? Who designed that code?

Like many here, I've worked on small and I've worked on big - and some of
my most head-scratching bugs have been on relatively small systems (a few
thousand lines). It's odd, but I've found that multi-MLOC code tends not
to present as many problems. (I don't know why. Maybe it's just because
people tend to be a bit more conservative on larger systems, but that's a
guess really. It's odd.)

Yup. Set a HW breakpoint on the conditions the stack trace showed to
cause the crash.

Well, actually no. If the program crashed, finding the cause is normally
little more than a formality for me. I'm sorry if that sounds like a
"pose"; it isn't meant to be.

No, the real head-scratchers are the non-crashing bugs, the logic bugs, the
"this output isn't what I expected" bugs. And even here, I have found that
ten minutes of careful thought is a good substitute for an hour with a
debugger. Of course, this may simply indicate that I never really used how
to use a debugger properly!

What are these techniques? And please do not say printf....

What is 3*4? And please do not say 12.

*Of course* I use printf (or rather, fprintf) to produce logging
information - and I can turn the log on and off at my leisure.

Most people who I have met who "dont need a debugger" ended up being
totally clueless on what one does or how to use it properly. I do not
accuse you of that I might add.

Perhaps you should. I don't normally use a debugger because I have found
that I take a long time to find bugs with them. It's entirely possible
that this is because I never learned to use one properly. On the rare
occasions when I /do/ use a debugger, I normally try divide-and-conquer
first. It's a workable technique, but perhaps you know better techniques.

 

[Morris Dovey]

No, you obviously don't. A shame. As it exists. You think a few of us
rebel against them for no reason?'

I won't question your motivation - it's very much none of my
business. Beyond that, I'm prepared to respect you as a forum
participant according to the quality of help you provide others
within the bounds of topicality. As is my normal wont, I'll apply
a multiplier that has to do with your ability to respect those
who don't echo your thoughts, methods, indentation/bracketing
style, editor preferences, etc.

Your behavior, rebellious or otherwise, doesn't convince me of
anything other than that you're capable of the behavior you
demonstrate.

If I see /only/ rebellious behavior on someone's part, I may
conclude that's all they're capable of - which would strike me as
unusual but uninteresting.

 

[David Resnick]

You seem to mistake my opinion of some of the hard core (and after your
post I guess that includes you) with reasonable team players with a good
practical knowledge of C that muck in and help people and don't gain
satisfaction from playing one upsmanship at every opportunity.

I am a reasonable person. Look at my posting history if you care to,
and you'll see that I'm helpful. I also think that the topic of this
group is portable C, which I think is a big enough area of interest to
be worth a group. I'm just not a zealot about it, and while I
sometimes redirect to other groups in my posts I do so, well,
helpfully. I'm not interested in topicality warfare or strict
enforcement, and think this group has become rather more tedious
because of it.

"When they don't". This is the issue you say. It's all a question of
when.

My guess in many cases would be "when they're not posting in
comp.lang.c". But as I don't know any of the "regulars" in person,
couldn't say if that's true.

90% of C I ever wrote never strayed from the target machine. So you
have a point about my lack of regard for overly pedantic standards
adherence.


None of this makes one iota of a difference with regard to a stack and
using a debugger of course. I migrated a huge code base from Windows to
OS/2 and then onto Linux. It wasn't that hard. Compile, read warnings,
tinker, run, debug. repeat. Works.

Must have been a hard thing to do on 2.5 million lines of code. And
would have been easier otherwise. The value and priority placed on
portability depends on the project of course.

I find them quite amusing. And they have a good point. I haven't seen
them savaging noobs or getting easy things wrong in their haste to show
off first.

Nor have I ever seen them contribute usefully. I don't find trolls
amusing. Nor do I find excessive topicality wars interesting, and
think some of the regulars are unhelpful in unpleasant ways. The tone
of the newsgroup could certainly be better.

Why aren't you telling others this?

As I said above, I in general tried to stay out of this whole mess.
Not sure why I got into this thread either. But yes, I think everyone
should be civil, and helpful. And some of the regulars fail in that.

Oh dear me. You let yourself down a little bit there. The "own name"
thing is ridiculous. "John Smith" could as easily be "Antonio Nonothing".

I think most of the regulars are probably posting in their real
names. I am. I think that adults who post in their real names
generally are less likely to post immature, ill considered twaddle
than those posting anonymously because everything posted is out there
forever (I see posts of mine back to 1990). Not guaranteed either way
of course, some people post idiocy in their own names.

-David

 

[Charlton Wilbur]

RH> No, the real head-scratchers are the non-crashing bugs, the
RH> logic bugs, the "this output isn't what I expected" bugs. And
RH> even here, I have found that ten minutes of careful thought is
RH> a good substitute for an hour with a debugger. Of course, this
RH> may simply indicate that I never really used how to use a
RH> debugger properly!

The most useful way I have yet found of using the debugger is to step
through lines of code, asking myself what I expect each variable to
contain and why. At some point, the computer's answer starts to
differ from what I expect, and that's where the bug is.

If it's not clear where in the code the bug is, I set 3 or 4
breakpoints at logical places and do the same thing. After this
paragraph of code, what do I expect each variable to contain, and why?

You probably use a series of printfs and some careful thought to
accomplish the same thing. Especially with some sort of tool where I
can say "watch this variable" and have its value displayed after every
step, I just find the debugger so much more convenient than adding and
removing (or commenting out, or conditionally compiling) debugging
printf statements.

Of course, I'm at the stage now where most of the time I can look at
the output and trace the code in my head and see where the divergence
happened; I don't think I could have gotten to that point without
using gdb a great deal, however.

Charlton

 

[Keith Thompson]

No, you obviously don't. A shame. As it exists. You think a few of us
rebel against them for no reason?'

To be perfectly honest, yes.

 

[Chris Dollin]

You are a wonder sir!

I already knew that.

I could never imagine not using one in a real world project
where one is extending, optimizing, fixing or refactoring
a huge legacy code base.

Then, with all due respect and independently of any abilities I
might or might not have, your imagination needs a good workout.

It is also incredibly useful, as I have stated before, to set HW break
points at known crash points, and at demonstrating program flow to new
recruits. As well as the ability to dynamically tweak parameters to force
certain situations you need to investigate.

All to their own, but I for sure would not hire or tolerate anyone who
felt that using a debugger was beneath them.

I have never said that I felt that using a debugger was beneath me. I
said that I didn't generally use one, and that was because I hadn't
needed one. Whether that's because I've done little multi-person C
work, or because I've not done embedded systems, or because I've built
code incrementally from the beginning, or what, I don't know; I don't
think it's because I'm a particularly amazing coder.

The next bit of serious C I write will be test-driven, of course. (My
Java code already is.)

I would like to reword. I would like to insert the word "generally" in there.

I don't think that helps.

 

[Chris Dollin]

Part of the definition of a "clique" is that everyone denies its
existence, but everyone knows it exists.

In which case -- since there are people who claim, rather than deny,
the existence of said clique -- it doesn't exist.

That's logic, that is.

 

[Kenny McCormack]

In which case -- since there are people who claim, rather than deny,
the existence of said clique -- it doesn't exist.

That's logic, that is.

You might want to look into what the currently accepted, common usage is
of the word "everyone".

 

[Dik T. Winter]

> Mind you, many of the harder problems to debug in the large (and of
> course multithreaded) group of apps I work on happen only under heavy
> load where breakpoints/etc are not really useful.

And of course there are the programs that fail, except when running
under a debugger.

 

[Richard]

To be perfectly honest, yes.

Then you're in denial or a fool.

 

[Richard]

I already knew that.


Then, with all due respect and independently of any abilities I
might or might not have, your imagination needs a good workout.

Or, I decided a long time ago that a debugger serves a useful purpose?

Did that cross your mind?

 

[Richard]

And of course there are the programs that fail, except when running
under a debugger.

That old chestnut.

These are very, very rare. I only had one of these where timing was all
important and I was stepping through during time critical sections -
more my fault than the debuggers.

And certainly far less than the amount of programs which are screwed up
by erroneous printf statements and asserts littering the code.

 

[Dik T. Winter]

>
> That old chestnut.
>
> These are very, very rare. I only had one of these where timing was all
> important and I was stepping through during time critical sections -
> more my fault than the debuggers.

They are possibly not frequent, but I have had too many of them under my
hands.

> And certainly far less than the amount of programs which are screwed up
> by erroneous printf statements and asserts littering the code.

And one of those also did no longer fail when statements were added or
strings were lengthened. (An off by one error during a garbage collection
phase.)

 

[Richard]

They are possibly not frequent, but I have had too many of them under my
hands.

Sure you have. All bugs are "too many".

And one of those also did no longer fail when statements were added or
strings were lengthened. (An off by one error during a garbage collection
phase.)

I don't know what that means. What garbage collection?

 

[Nick Keighley]

    RH> No, the real head-scratchers are the non-crashing bugs, the
    RH> logic bugs, the "this output isn't what I expected" bugs. And
    RH> even here, I have found that ten minutes of careful thought is
    RH> a good substitute for an hour with a debugger. Of course, this
    RH> may simply indicate that I never really used how to use a
    RH> debugger properly!

The most useful way I have yet found of using the debugger is to step
through lines of code, asking myself what I expect each variable to
contain and why.

Aren't you worried the sun will go super giant before you finish?
You must be debugging quite small programs.

Some of the systems I work on drop their comms links
or do other RT related things if you stop them.

 

[Richard]

Aren't you worried the sun will go super giant before you finish?
You must be debugging quite small programs.

He didn't say he stepped through the entire program. Sheesh.

Some of the systems I work on drop their comms links
or do other RT related things if you stop them.

So what?

What that has to do with when you CAN use a debugger to help is
debatable.

 

[Dik T. Winter]

>
> I don't know what that means. What garbage collection?

Local memory management plus garbage collection.

 

[Chris Dollin]

Or, I decided a long time ago that a debugger serves a useful purpose?

Did that cross your mind?

I meant exactly what I said: whether or not a debugger serves a useful
purpose, or what you decided, if you can never imagine not using one [etc],
your imagination needs a good workout. It's a comment about your power
of imagination, not about debuggers.

 

[Nick Keighley]

most people are claiming *they* don't use debuggers (much).
Isn't possible that different people do things in different ways?


I'm doing that. I don't use a debugger much


what's wrong with a backtrace on the core dump? I can see
the point of pointing in a breakpoint if some parameter goes hay-wire
after several hours. That seems to be rare in my environment.
I have caught bugs of the "how the heck did *that* get set to *that*
value? (It read it from the database).


never done that. Why can't they read the code?


I may have done that once. Seems a bit odd to me. Changing
the value of parameters seems odd to me...



the "beneath them" crack is getting a bit old.

If you don't think the ability to set HW break points/watch conditions on
complex matches in order to stop the process possibly hours into a run
is not useful then I really do not know what to say. if you dont think
the ability to dynamically change run time parameters to force certain
trigger parameters is useful then I'm astonished.

I must astonish you then

The only thing I can guess is that you work on very small, well
structured code bases for which you are almost solely responsible for.
nope.


And fair enough.

But some people here recommend against using them. There is a difference.


Fair enough. Possibly. But I suspect your productivity would be much
better if you used one regularly. maybe. Maybe not. We'll not agree I'm
sure.


No. I would not.




"or the value of a variable or two". This is so open to interpretation
it is unbelievable. And as for the stack trace! What? There is NO
stack. Remember :-;


I disagree with them. Of course I respect them. I wonder how many
existing code bases they maintained and extended? I wonder how good
debuggers were back then? TBH, I'm sick of seeing that quote trotted
out. I know what a debugger can do. I use it to do it. There is NO WAY I
could find those bugs from a print out of a 2.5 Million line code
base.

ah well mines only a third that size.

I suspect that the debuggers available then were a fraction of
what is available now.

I would be interested to hear which bits of the following article you
disagree with:

http://dirac.org/linux/gdb/01-Introduction.php

Or is that guy wrong? Is Stallman wrong?




It is IMO. Note the IMO. Maybe we have worked on different things. I can
only have my reasoned opinion. Developing code without using a good
debugger is, IMO, madness.


I do. And more importantly familiarisation.

never done this. I read the code.


<snip>

 

[Richard Tobin]

[/QUOTE]

never done that. Why can't they read the code?

I have a few times found it very hard to understand code, and been
enlightened by seeing it in action under a debugger. It doesn't seem
very surprising to me that this should be helpful. Do you never
find code hard to understand?

-- Richard