What is a stack frame?

[Kenny McCormack]

Then you're in denial or a fool.

I vote: Both.

 

[Charlton Wilbur]

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

No, I use my skills at perceiving obvious things to narrow down where
I think the bug is beforehand. I rarely need to use the debugger on
more than 20-25 lines of code at a time.

Charlton

 

[Richard Heathfield]

Richard Tobin said:

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?

Yes, sometimes. And yes, I used to use a debugger in an attempt to
understand such code. Perhaps this works for some people, but it never
really worked for me.

 

[Richard]

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.

Typical clc behaviour. Clearly I do not mean on every fricking program.

Please read the criteria I gave. In those conditions I could not:

And if YOU can walk onto a new project with a 2 million line code base
and extend it or bug fix it and NOT need a debugger then I simply do not
believe you and can only assume you are mistaking my meaning.

Sorry and all that.

 

[Richard]

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

Of course. Some things. Some people try to walk across the sea. I prefer
to take a boat.

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

"much"

Horses for courses. I can feel my words being twisted.

what's wrong with a backtrace on the core dump? I can see

Nothing. Thats one way. if you think, as you seem to, that a debugger is
only there for a program crash. I really thing you have no real
experience or have not been properly instructed in how to use one.

the point of pointing in a breakpoint if some parameter goes hay-wire
after several hours. That seems to be rare in my environment.

Good for you.

I have caught bugs of the "how the heck did *that* get set to *that*
value? (It read it from the database).

I dont know. I get the impression from some of these replies that some
people really do not know how to use a debugger properly.

It is easy to tweak run time values for testing or probing possible
weaknesses. It is useful for reaching a complex state and then breaking
in order to check certain rarely called functions. Only in CLC have a
been told these things are not "necessary".

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

You really do not see how stepping through and seeing a code stack and
being able to examine run time parameters makes it easier? Wow.

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

Then you do not now how to use a debugger properly. I know you'll not
like that, but there we are. If you can not see how tweaking run time
values can GREATLY simplify development and bug hunting then I must
question your experience of working in a large team on a big code base.

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

Not really.

I must astonish you then

No. Disappoint me. You really think the things above are not helpful?
Really? Why are these things developed? How do YOU do similar to help you?

nope.

It seems that way.

ah well mines only a third that size.

Still huge. And still greatly simplifed by a good debugger. The rest of
the world outside of clc sets great store by them. And please dont quote
me that bloody Kernighan quote again.

never done this. I read the code.

Then you're wasting time. A good printout is of course a wonderful thing
to have. But it is limited in what you can "model" in your head in a
certain time.

You can not possibly read 2 million lines of code and understand it
without seeing it in action : and a debugger and profiler allow just
that.

And if you think you can you're deluding yourself.

You can keep the working set in your head 30 seconds into a real time
running of a program that size?

No. You can not.

Well, thats it for me on this thread. it's tiresome listening to some of
the "big me" statements in here. You're all wonderfully brilliant and
dont use debuggers I'm sure.

 

[Richard]

Richard Tobin said:


Yes, sometimes. And yes, I used to use a debugger in an attempt to
understand such code. Perhaps this works for some people, but it never
really worked for me.

How the hell can it NOT work for you?

How in gods name can seeing the code stepping though NOT be easier than
reading a print out?!?!?!?!? Even as an additional view in conjunction
with the printout it can ONLY be easier.

I really have had enough of some of the ludicrous claims here.

Why?!?!?!?

 

[Richard Tobin]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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?

[/QUOTE]

Yes, sometimes. And yes, I used to use a debugger in an attempt to
understand such code. Perhaps this works for some people, but it never
really worked for me.

Fair enough. I am just surprised by the underlined comment above,
which suggests that there must be something wrong with you if you
find it useful.

-- Richard

 

[Richard Heathfield]

Richard said:

How the hell can it NOT work for you?

How in gods name can seeing the code stepping though NOT be easier than
reading a print out?!?!?!?!?

Well, it doesn't really tell me anything that I can't find out quicker by
reading the code in an editor. And yes, I used to print stuff out, too,
until I eventually realised that that was a waste of time and paper.
(Actually, the paper wasn't completely wasted, because I used to take it
home so that my children could draw on the back...)

I don't reject the idea of using a debugger. I'm not claiming that it's
wrong or sinful or a crutch or a sign of weakness. I'm just saying it
doesn't work for me. I can certainly understand how it might work for
other people, but for me it just doesn't cut it. It's good for a backtrace
on occasion, and *sometimes* I hit a problem where it seems to me that I
could benefit from stepping through the code, but it really doesn't happen
all that often.

Obviously you don't have to believe me (and it seems that you don't), but
it's not as if I'm making any great claim. If anything, I'm claiming
ignorance, since it's clear that you get great benefits from stepping
through code, benefits that I don't know how to get. (Yes, of course I
know how to step through code. I just don't know how to benefit from it. I
*have* used several debuggers, and I even wrote one once. I'm just not
much cop at deriving the same benefits from them that you do.)

Some people drive automatics, and some of those are advocates of automatics
- they can't understand how anyone could find it /easier/ to drive a car
with manual transmission. And yet I do. I've tried an automatic, and I
kept stalling it (which the owner claimed was impossible... and I wasn't
even /trying/ to stall it! I was trying to drive it!). I'll stick to
manual, thanks. For those for whom automatics work, they're presumably the
best thing since sliced bread, but *I* can't use them as effectively as I
can use a manual transmission gearbox.

Same with debuggers (except that I've hardly ever stalled a debugger).
Perhaps it's a mind-set thing.

Even as an additional view in conjunction
with the printout it can ONLY be easier.

Understanding that not everybody thinks the same way you do is difficult.
But it *is* possible.

I really have had enough of some of the ludicrous claims here.

I haven't seen any particularly ludicrous claims here. If anyone is
*recommending* that other people should not use debuggers (and if that
recommendation was made, I missed it), then that would indeed be
ludicrous. Just because *I* don't find debuggers to be a great deal of
help, that doesn't mean that someone else won't.

Why?!?!?!?

Because everybody's different?

 

[Richard Heathfield]

Richard Tobin said:

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Yes, sometimes. And yes, I used to use a debugger in an attempt to
understand such code. Perhaps this works for some people, but it never
really worked for me.

Fair enough. I am just surprised by the underlined comment above,
which suggests that there must be something wrong with you if you
find it useful.[/QUOTE]

Perhaps Nick K can answer that, since he wrote it. Personally, I think
anyone who works better with a debugger should use one, and anyone who
works better without one should be allowed to work without one, and anyone
who works better with /occasional/ recourse to a debugger should be left
to do that. ***Whatever works***, right?

 

[Ben Pfaff]

How in gods name can seeing the code stepping though NOT be easier than
reading a print out?!?!?!?!? Even as an additional view in conjunction
with the printout it can ONLY be easier.

You sound so provincial, as if your own preferences are the only
possible correct ones. Indeed, I have heard plenty of
programmers say that the first thing they do with new code is to
step through it. But that is not what plenty of other
programmers prefer. Personally, I use a good programmer's editor
to follow the code flow. Often, I find that the *possible*
control flow is more interesting than the *specific* control flow
in any given instance.

 

[jacob navia]

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.

Obviously YOUR imagination has a great power. You can even believe
the stories you tell us here.

It is impossible for any human to debug a program written by others
without a debugger, of course if the program has a certain size
(bigger than, say, 1500 -2000 lines)

Of course with the imagination you have, you can load all that
program in memory, analyze all possible paths, then pinpoint
the logic error that makes variable "m" have a value off by one
in sequence 1534 of nested loop 2987.

YOU do not need a debugger obviously, you are a debugger.

I am happy with being human, and using my imagination to do
more interesting tasks. I like playing music, for instance.

 

[jacob navia]

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[/QUOTE]

He is playing superman.

Of course, we are just humans, not superhumans, that can
beat a computer. We USE computers, we do not try to beat them,
using our mind to do things it was designed to do.

 

[jacob navia]

I already knew that.

Yeah sure. Please... just put it in Technicolor.

As I told before, in dry black and white I do not believe you
a single word!

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

Your imagination knows no limit. I think that you even believe
your own stories!

 

[Ben Pfaff]

It is impossible for any human to debug a program written by others
without a debugger, of course if the program has a certain size
(bigger than, say, 1500 -2000 lines)

That's a ridiculous statement. I have personally debugged
programs written by others that are multiple orders of magnitude
larger than that without using a debugger. Some language
implementations don't even have debuggers, and yet people manage
to write and debug large programs written in those languages.

What's wrong with you and Richard, that you have to believe that
everyone works exactly the same way that you do?

 

[santosh]

jacob navia wrote:

It is impossible for any human to debug a program written by others
without a debugger, of course if the program has a certain size
(bigger than, say, 1500 -2000 lines)

How did they program before debuggers then?

 

[jacob navia]

jacob navia wrote:



How did they program before debuggers then?

They wrote "mini debuggers" with printf statements.

I do this sometimes, specially when debugging my debugger,
that I wrote for lcc-win.

You suspect that this variable or that variable has a
wrong value, then you write

printf("X is %d\n",x);

AD NAUSEUM.

Or, you stare at the listing for hours, and try to
figure out where it can go wrong.

In those times programs were much smaller than today,
and people could have a good intuition of where it
could go wrong by looking at the symptoms.

 

[jacob navia]

You sound so provincial, as if your own preferences are the only
possible correct ones. Indeed, I have heard plenty of
programmers say that the first thing they do with new code is to
step through it. But that is not what plenty of other
programmers prefer. Personally, I use a good programmer's editor
to follow the code flow. Often, I find that the *possible*
control flow is more interesting than the *specific* control flow
in any given instance.

You are debugging programs that have a well defined control flow, not
event driven

The problem is that you need to see the sequence of events, then,
when using a debugger, you will notice that at *that* line,
an interrupt could happen that trashes some register, making
your variable change value, what makes the program go into
the path it could NEVER had taken!

Bugs are that:

BUGS

They do not follow the rules!

 

[santosh]

You are debugging programs that have a well defined control flow, not
event driven

The problem is that you need to see the sequence of events, then,
when using a debugger, you will notice that at *that* line,
an interrupt could happen that trashes some register, making
your variable change value, what makes the program go into
the path it could NEVER had taken!

This could have been stopped with a simple assert on that variable.

<snip>

 

[Ian Collins]

You sound so provincial, as if your own preferences are the only
possible correct ones. Indeed, I have heard plenty of
programmers say that the first thing they do with new code is to
step through it. But that is not what plenty of other
programmers prefer. Personally, I use a good programmer's editor
to follow the code flow. Often, I find that the *possible*
control flow is more interesting than the *specific* control flow
in any given instance.

That's where a good debugger (good in this case means integrates with
your preferred editor) can give you the best of both worlds. Both live
and static browsing.

 

[Ian Collins]

It is impossible for any human to debug a program written by others
without a debugger, of course if the program has a certain size
(bigger than, say, 1500 -2000 lines)

Debug, or understand? I Both cases, I'd start of by adding unit tests
to validate my understanding of the code. I most certainly wouldn't
attempt to modify the code without adding the tests first.