What is a stack frame?

[Nick Keighley]

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

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]

presumably there's something wrong with me since I wrote it.
I'd pretty well concur with most of that post.

 

[Richard Bos]

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)

I _knew_ there had to be something that proves me not human. Thank you,
thank you jacob, for proving that I'm superior to mere homo sapiens.

Richard

 

[Chris Dollin]

Richard wrote:


Richard wrote:

I have seen people in
this group claim that a good C programmer needs no debugger.
I've certainly claimed that I don't use one (except to get
stacktraces).
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.
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.

Just more than Richard-with-no-aftername's.

You can even believe the stories you tell us here.

Cite me a "story" I've told that you believe to be false (and
not a piece of humour). Tell me to my face I'm lying.

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)

If you say so, Jacob.

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.

Richard said he couldn't imagine not-using-a-debugger-etc. I
can. That doesn't mean my imagination somehow enables
second-stage-Lensman abilities in me; I didn't claim it did,
and I think if you look back at the thread, you'll see
that I didn't.

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

Thank you, Jacob, it's nice to have one's talents appreciated.

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

I too have imaginative hobbies. Imagination doesn't localise.

 

[Richard Bos]

No, you never did that. You wrote special purpose debuggers,
(printf statements output statements whatever),

That, my dear Frenchman, is called "shifting the goalposts" in English.
It is not generally seen as a sign of the strength of one's arguments.

Richard

 

[Chris Dollin]

Richard wrote:


Richard wrote:

I have seen people in
this group claim that a good C programmer needs no debugger.

I've certainly claimed that I don't use one (except to get
stacktraces).

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.

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.

I took you to mean "routinely", and responded on that basis;
sorry for not being clearer that I wasn't weaseling on rare
instances.

I took you to be saying: you could never imagine /routinely/ not using
one in a real world project here one is extending, optimizing, fixing
or refactoring a huge legacy code base.

I'm saying: your imagination needs working on. I /can/ imagine
that. I also think its possible in principle to do that, and
increasingly possible to do that in practice -- of course I
could be wrong, because I don't have your experience in the
field.

Please read the criteria I gave.

I did. (And I wondered in passing why you said "refactoring" and didn't
mention unit testing.)

And if YOU can walk onto a new project with a 2 million line code base

Aren't those two mutually exclusive?

and extend it or bug fix it and NOT need a debugger then I simply do not
believe you

If we're sharing the same meaning for "debugger", and assuming that
the project is in some domain I have relevant expertise in, then
feel free to disbelieve me, since we're unlikely to ever put it
to empirical test: but I think you're over-stating the case.

and can only assume you are mistaking my meaning.

I don't think I am (but I do think you're wilfully mistaking mine).

Sorry and all that.

S'OK.

 

[jacob navia]

nope. event driven

In that case you are telling us stories.

Personally I just do not believe you. I have seen bugs using debuggers
that you would *never* have seen because they are provoked by interrupts
incorrectly handled or memory being trashed by libraries that you
thought safe, and many other kinds of goodies.

It is very easy to tell stories here, and this discussion is now
useless.

Anyone can tell stories. I am in face of super heroes that do not
use debuggers and understand (like "Flash gordon" tells) an assembler
program without even knowing the source code.

Yeah, great. Either his program was doing

2+2 = 5

and he spotted immediately the bug obviously, or he has read too
much science fiction and is playing superman.

 

[Richard Bos]

Bugs arise in places you do not expect them.

I expect bugs to arise everywhere. Granted, sometimes they arise
nowhere, which is certainly not what I expect.

How can you know that a buffer overflow is trashing your values?

You can't. Not any desk check can catch that.

Any halfway well-done desk check will tell you whether a statement
overflows a buffer.

Richard

 

[Richard Tobin]

[/QUOTE]

Perhaps someone who does this a lot could explain how it has
enlightened them. I use a code browser and *that* helps.

I don't do it a lot, but I have found it very useful in some cases.

An example is when I was trying to understand a virtual machine
implementing another programming language. There were switch statements
with hundreds of cases, and many possible paths through the code.

Running it under a debugger let me see which parts of the code handled
the common cases. The overall looping structure became apparent,
because you could see the same code getting run over and over again.
The growth and shrinkage of stacks was clear. It showed the dynamic,
as oppsed to static, structure of the program.

An analogy: imagine looking at an old wind-up clock and trying to
understand how the gearing works. The obvious thing to do is start it
up with the cover off and see how things move.

-- Richard

 

[Chris Dollin]

... or he has read too much science fiction ...

Like "too much chocolate", this is not feasible.

 

[jacob navia]

I expect bugs to arise everywhere. Granted, sometimes they arise
nowhere, which is certainly not what I expect.


Any halfway well-done desk check will tell you whether a statement
overflows a buffer.

Richard

void dowork(char *buffer,size_t siz)
{
for (int i=0; i<siz;i++) {
buffer=0;
}
}

Not any amount of code review will catch the case where
siz is wrong because the calling procedure had a memory
overwrite.

 

[lawrence.jones]

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)

You remind me of the people in a sci-fi story I read that insisted it
was impossible to do arithmetic without using a calculator.

-Larry Jones

I've got PLENTY of common sense! I just choose to ignore it. -- Calvin

 

[Chris Dollin]

You remind me of the people in a sci-fi story I read that insisted it
was impossible to do arithmetic without using a calculator.

/The Feeling of Power/, Isaac Asimov.

 

[Flash Gordon]

jacob navia wrote, On 13/03/08 09:55:

Anyone can tell stories. I am in face of super heroes that do not
use debuggers and understand (like "Flash gordon" tells) an assembler
program without even knowing the source code.

That is not what I said. The language I did not know was Coral 66 and I
stated this. The assembler was one that I had only just been on a course
to learn and I had never seen the code before I started debugging it.
The really horrible project was a different and very horrible assembler.

In over 20 years of programming on a range of systems in a range of
application domains I have done a lot of different things.

Yeah, great. Either his program was doing

2+2 = 5

and he spotted immediately the bug obviously, or he has read too
much science fiction and is playing superman.

No. For one of the most serious bugs the on the assembler program I
looked at the symptoms...

Almost as soon as you touch the controls on the external controller
the system crashes.

Thinks, those controls are being sent to the system over an interrupt
driven serial link. Must check the interrupt handler.

Read the comments for the interrupt handler and the code itself. The
comments say the rest of the code must not use ar6 and the interrupt
handler uses ar6 without saving it.

Thinks, must check if this rule is violated.

Check the rest of the code for references to ar6 and lo and behold
there they are!

Change interrupt handler so it saves and restores ar6.

Test, it no longer crashes as soon as you touch the controls.

That was just one of the things I debugged, in this instance it really
was simply by reading the comments, reading the code, thinking and
(possibly) using search tools on the code.

This was an embedded system and we did not have a debugger I could hook
up. All I could do was get the hardware engineer to hook up a logic
analyser (which meant putting the card on an extender which changed
timings introducing other problems with the video processing. However,
the logic analyser was a lot less helpful than you might expect due to
the nature of the processor.

Other bugs on the system turned out to be either design or algorithm
bugs, and they were solved by reverse engineering from the code what the
algorithm was and then studying the algorithm and thinking about how it
would behave under certain conditions.

 

[Flash Gordon]

jacob navia wrote, On 13/03/08 14:42:

I expect bugs to arise everywhere. Granted, sometimes they arise
nowhere, which is certainly not what I expect.


Any halfway well-done desk check will tell you whether a statement
overflows a buffer.

void dowork(char *buffer,size_t siz)
{
for (int i=0; i<siz;i++) {
buffer=0;
}
}

Not any amount of code review will catch the case where
siz is wrong because the calling procedure had a memory
overwrite.

A code review of that function won't. However code reviews are not
limited to just one function, all functions get reviewed including the
ones calling dowork, and when the one calling it is reviewed is when you
can find the bug in it.

Or alternatively we can turn your argument on its head and say that
single stepping through that function won't tell you it is overflowing
the buffer because all you will see is that it is not going beyond the
size that is passed in. So with a debugger you can also only find the
problem if you look beyond just that one function.

 

[Richard Bos]

I expect bugs to arise everywhere. Granted, sometimes they arise
nowhere, which is certainly not what I expect.


Any halfway well-done desk check will tell you whether a statement
overflows a buffer.

void dowork(char *buffer,size_t siz)
{
for (int i=0; i<siz;i++) {
buffer=0;
}
}

Not any amount of code review will catch the case where
siz is wrong because the calling procedure had a memory
overwrite.

If you recant your accusation of lying in public and with grace, I will
explain to you how it can.

Richard