mnemonic

[jacob navia]

Maybe you should try using a language without a debugger, it does
wonders for your testing and debugging skills.

Debugging skills have nothing to do with a debugger.
A debugger lets you come quickly to a solution, but to
come to the solution you have to have some debugging
skills.

And this

"Either have debugging skills or use a debugger" is a non-issue.
This things aren't alternatives, and having a debugger doesn't
"spoil" your debugging skills.

C developers are spoilt rotten with decent debuggers, they have their
uses and they are an excellent means of proving the cause of a problem,
but I think overall they blunt rather than sharpen ones skills.

You see?

Sheer nonsense. But go ahead. You do not use a debugger.

We all make mistakes, we just use different strategies for fixing them.
I prefer my unit tests, if I have to use my debugger, I know my tests
are too coarse. A year of PHP development without a debugger taught me
that lesson.

Nonsense. Unit tests test each unit separately. They can't test a bad
interaction between two units because a flaw in the design. Each unit
works perfectly well but there is a situation the design did not
foresee.

But obviously only stupid people have flaws in their design and need
a debugger, I hear it coming.


The only thing you gain without a debugger is that you debug MUCH
more slowly.

 

[Ian Collins]

Debugging skills have nothing to do with a debugger.

Which was may point.

You see?

Sheer nonsense. But go ahead. You do not use a debugger.

Who says I don't? But that that use is more as a tool to investigate
legacy code and to confirm a hypothesis. With new code, if a change
breaks a test, just undo it and try again.

Nonsense. Unit tests test each unit separately. They can't test a bad
interaction between two units because a flaw in the design. Each unit
works perfectly well but there is a situation the design did not
foresee.

I've never had that problem, units build of what comes before them.
Attempting to mock every other part of a system is seldom a good idea.

The only thing you gain without a debugger is that you debug MUCH
more slowly.

Maybe, but you soon learn how to write code with fewer bugs. As I said,
try working without a debugger for a while, you'll be surprised how fast
you can go. There are many in XP circles who firmly believe resorting
to the debugger is a last resort and shows your tests aren't good
enough. My time with PHP showed me they are probably right.

 

[RoS]

In data Sat, 03 Nov 2007 01:12:54 +0100, Tor Rustad scrisse:

Richard wrote:

[...]

2nd note : if a system crashes I can guarantee that i can debug it to
the point of the crash quicker than you can read and understand 500000
lines of C code and run it through in your head with all possible data
input and come to a guess at where it might crash .....

I can guarantee you, on some systems others will find the bug faster
without a debugger, than you will.

Some of the C code I have written, "cannot" be debugged in production.
The binary is protected by hardware mechanisms, if a trigger goes off,
the current state of the program erased.

in that case if the debugger for the proper assembly is not useful
change language (or rutines)

if a program is not debbuggable in assembly or in the language that
descrive all the states of machine afther each instruction:
that programme (or langugage) is irremidiable bugged because
programmer doesn't know what an easy instruction does

if some of you don't see what i see, some of you is too much young

 

[James Kuyper]

Debugging skills have nothing to do with a debugger.
A debugger lets you come quickly to a solution, but to
come to the solution you have to have some debugging
skills.

A debugger is like any other device; reliance upon the device gives you
less practice with the skills that would be needed to achieve the same
result if the device were unavailable. How important that effect is
depends upon how likely it is that the device might be unavailable. With
respect to debuggers, that depends entirely upon what kind of platforms
you're programming for. There might not be any debugger for some
platforms, or the only debugger might be one that is so different from
what you're used to that it might as well not be available.

If you work exclusively on one or two well-supported platforms, you
might not even notice this problem; that doesn't make the problem any
less real for those who do have to deal with it.

I say this as someone who relies heavily on the debugger when I can, and
relies heavily on inserting fprintf(stderr, ...) when I can't use the
debugger. I usually find both techniques a lot faster than desk checking
(which I also do). If I made a mistake that couldn't be caught by the
compiler when I wrote the code, I usually continue making that same
mistake when I re-read the code.

 

[santosh]

RoS wrote:

<snip>

Are you "aVb"? If so please don't keep changing pseudonyms. It's rude
behaviour.

 

[Al Balmer]

clear code and complex code are not opposites, if an expression gets too
many parentheses it just looks a bit weird to me. That doesnt mean I find
the expression complex. On top of that, I cant remember getting into trouble
understanding code on a single line/expression. (obfuscated contest code
doesnt count) Complex code has more to do with the total structure and
dependencies on each other.

Exactly. That's why the OP should reconsider his coding effort. You
will note that I was commenting on why it *appears* so complex. Overly
complex code is usually a sign of bad design.

 

[Tor Rustad]

jacob navia wrote:

[...]

Let me present a dissenting view. For me, a debugger is essential.
Without it you can't debug a complex program, isn't it obvious?

You are maintaining a compiler right?

I can see why you find a debugger very useful for locating *known
problems*. A compiler, is like a complex batch program, where an error
case is easy to reproduce, just try to compile the same source again.

Now, imagine debugging a kernel module instead, or some other real-time
code, and no, you might not be able to reproduce the error condition in
your test environment.

Or, like I mainly work with, try to track down security bugs, before
anyone out there do.

A debugger lets you debug a program.

Not always, some programs *cannot* be debugged in production.

I can add, some programs, should be tested to death, before shipping.
It's, somewhat difficult to debug mission-critical control system, in
deep space, for example.

But of course I use a debugger because I have bugs, contrary to
the super heroes in this group that never do any mistake.

A debugger isn't always the best tool for the job. How many race
conditions have you tracked down via a debugger?

How could the Therac-25 accidents been avoided? Via a debugger?

 

[Richard]

I get the feeling you might have misread the first sentence ofthe quote.
At least you see to be arguing as if it said: "Debugging is twice as hard
as getting the code right int he first place.". rather than what it
really says.


Again, this leads me to believe you've read something different to
what's actually written..

Martien

Again, for the record, its not what I *read* or understood, its about
why and when this quote is trotted out. See other posts.

 

[Tor Rustad]

In data Sat, 03 Nov 2007 01:12:54 +0100, Tor Rustad scrisse:
[...]

Some of the C code I have written, "cannot" be debugged in production.
The binary is protected by hardware mechanisms, if a trigger goes off,
the current state of the program erased.

in that case if the debugger for the proper assembly is not useful
change language (or rutines)

FYI, I was talking about software in a TRSM (Tamper Resistance Security
Module).

 

[Richard]

jacob navia wrote:

[...]

Let me present a dissenting view. For me, a debugger is essential.
Without it you can't debug a complex program, isn't it obvious?

You are maintaining a compiler right?

I can see why you find a debugger very useful for locating *known
problems*. A compiler, is like a complex batch program, where an error

Surely if its not a "known" problem then its, err, not a problem?

case is easy to reproduce, just try to compile the same source again.

Now, imagine debugging a kernel module instead, or some other
real-time code, and no, you might not be able to reproduce the error
condition in your test environment.

Or, like I mainly work with, try to track down security bugs, before
anyone out there do.



Not always, some programs *cannot* be debugged in production.

So what? It doesn't preclude it being useful in 99.999999999% of other
cases. Anyway I have frequently connected a debugger to live systems to
catch errors and certain watch conditions.

I can add, some programs, should be tested to death, before
shipping. It's, somewhat difficult to debug mission-critical control
system, in deep space, for example.

And it's not possible to hold your breath for 28 minutes either. I'm not
sure how this point about deep space in anyway takes anything away from
how useful a debugger is in the real world.

A debugger isn't always the best tool for the job. How many race
conditions have you tracked down via a debugger?

I would not use a debugger to unblock the u-bend under my kitchen sink
either. But I would use it to catch errors in a real world C program ....

How could the Therac-25 accidents been avoided? Via a debugger?

And a debugger can not cure AIDs or cancer either. No one said it was
the answer to the worlds problems.

The view of some of the regulars here is quite astonishing and makes me
wonder how many have really worked in Industry on large code bases
maintained by multiple programmers across the world.

 

[Tor Rustad]

[...]

A debugger isn't always the best tool for the job. How many race
conditions have you tracked down via a debugger?

I would not use a debugger to unblock the u-bend under my kitchen sink
either. But I would use it to catch errors in a real world C program ....

You sounds more like a junior programmer, maintaining a prototype.

 

[Richard]

[...]

A debugger isn't always the best tool for the job. How many race
conditions have you tracked down via a debugger?

I would not use a debugger to unblock the u-bend under my kitchen sink
either. But I would use it to catch errors in a real world C program ....

You sounds more like a junior programmer, maintaining a prototype.

Well, I can say with some authority I clearly have much better and more
detailed knowledge of how to use a debugger for what it was intended to
do than you. Why you want to throw in straw men about the minority of
cases where a debugger might not be useful is quite beyond me. No one
described it as a "single solution for all cases".

From your rather "high level perch" I wonder why you are even discussing
debuggers since you are clearly too clever and senior to have to use one.

But thank you for the kind words regardless :-;

 

[J. J. Farrell]

The view of some of the regulars here is quite astonishing and makes me
wonder how many have really worked in Industry on large code bases
maintained by multiple programmers across the world.

Now there's a sentiment I agree with entirely, though I suspect we're
thinking of different groups of regulars.

 

[Richard Bos]

I'll post this again as it is interesting and a good read for newbies.

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

Still, all to their own.

Here is a quote from the above link

A link which, it would be wise to note, was written by someone writing a
tutorial for GDB - hardly unprejudiced.

,----
| You'll be able to find and fix your bugs faster using a symbolic
| debugger like GDB. However, this isn't to say that printf() has no use
| in debugging. Sometimes it's the best way to go. However, for real code,
| a debugger can almost always get the job done orders of magnitude faster
| and easier.

Says... someone explicitly advocating GDB. Well, my experience
disagrees. Even when a debugger is faster than using printf(), it's
hardly ever orders of magnitude faster.

And using a debugger is always more elegant, and if you
| don't care about elegance, you should quit programming on Linux
*Snigger*

Using printf is the resort of the hobbyist programmer or the lone Guru
(who hasn't mastered a decent debugger ... :-

*Sigh* And, of course, the art of the desk-check is being forgotten by
GDBer and printf()er alike...
Come back to talk about gurus, grasshopper, when you can desk-check your
code blindfold, standing on one leg above a pail of water.

Richard

 

[Richard Bos]

Of course it isn't. But it would be fairly ridiculous to suggest that
any form of debugging an existing code base is NOT done with a
"debugger" of some description.

It would be ridiculous. However, for the wise, "debugger" means
"programmer who finds and removes bugs", and not "program which steps
through another program". The former _may_ use the latter, but by no
means has to.

Richard

 

[Nick Keighley]

debugging != using a debugger

this keeps on being said...

Of course it isn't. But it would be fairly ridiculous to suggest that
any form of debugging an existing code base is NOT done with a
"debugger" of some description.

this is just silly. You're claiming a debugger is essential to
debugging
therefore if someone is debugging they are using a debugger. Make your
mind up.

A debugger is a special purpose program that is attached to a running
program
(or used to analyse a "core" dump) to aid in finding bugs in programs.

There are other ways to find bugs.

People who advocate littering code with
printfs are plain wrong IMO.

well depending what you mean by "littering" and "printf". My programs
typically write to log files. When Things Go Wrong the logfile at
least tells you
what the program was *trying to do. This sometimes happens on a
different
continent from my current location...

Yes, it might have its uses occasionally,
but any changing of the code to "debug" is generally considered a bad
thing.
"generally"?


From some of the comments I read here, I often wonder if the people
knocking debuggers have any idea whatsoever of just what they are, how
they work and the results they can achieve.

I use debuggers sometimes. I just don't think they are always useful.

One of my favorite uses of a debugger is simply to step through code to
get a feel for the control flow.

now this I find strange. Debugging is fixing faults. Why would you
step through the program at random (or is there a purpose?). The
programs I deal
with have soft RT requirements. If you start single stepping then the
program
looses data, drops comms links and fails to do things on time. They
are also
large. Stepping through the code "to get a feel for the control flow"
sounds odd.

Maybe this *is* an age thing.

Ability to step over calls and just
examine the returned data etc is much easier than "imagining" it by
reading code no matter how well and clearly that code is written and
annotated.

well I'll do that if I'm stuck. And debuggers are handy after crashes.
But not all bad things crash the program.

I have to deal with bugs where debuggers are not available. In fact
where
I am not even present.

Programs that record what tehya re doing are handy.

 

[Richard]

debugging != using a debugger

this keeps on being said...

Yes, by me too.

this is just silly. You're claiming a debugger is essential to
debugging
therefore if someone is debugging they are using a debugger. Make your
mind up.

A debugger of some description.

A debugger is a special purpose program that is attached to a running
program
(or used to analyse a "core" dump) to aid in finding bugs in programs.

There are other ways to find bugs.

Yes. We explored that a lot in the thread.

well depending what you mean by "littering" and "printf". My programs
typically write to log files. When Things Go Wrong the logfile at
least tells you
what the program was *trying to do. This sometimes happens on a
different
continent from my current location...

None of which has anything to do with why debugging is not a good thing.

"generally"?

Yes. Generally.

I use debuggers sometimes. I just don't think they are always useful.

No. But generally they are. Its why they were invented.

now this I find strange. Debugging is fixing faults. Why would you
step through the program at random (or is there a purpose?). The

Yes there is a purpose. Reread the sentence - it is clear enough. To
step through the code to understand the program flow. The ability to
force logic conditions to step through less likely states is obviously a
boon to the investigative programmer. Debugging code is easier with a
knowledge of how it is constructed and runs.

programs I deal
with have soft RT requirements. If you start single stepping then the
program
looses data, drops comms links and fails to do things on time. They
are also
large. Stepping through the code "to get a feel for the control flow"
sounds odd.

So why mention it. Not everyone is RT.

Maybe this *is* an age thing.

I have no idea what you mean. The great majority of SW is not RT and a
debugger and debugging and associated techniques are not rocket science
and bring a lot to the table.

well I'll do that if I'm stuck. And debuggers are handy after crashes.
But not all bad things crash the program.

No one said they did. But a debugger can halt a program using predefined
watch conditions. Makes it far easier to locate the problems. Even in RT systems.

I have to deal with bugs where debuggers are not available. In fact
where
I am not even present.

Programs that record what tehya re doing are handy.

Yes. And this is a form of debugging.

 

[Gray Area]

They can be, if you use them abusively. On the other hand, *lack* of
parentheses can be annoying and useless in code for the same reason.


Perhaps *you* have perfect memory, but *I* don't. I'd rather remember
a simple guideline than a slew of rules, because to be perfectly
frank, I have better things to spend my few remaining brain cells
on.

Indeed. In fact many moons ago I used the Watcom compiler(cant recall
what version... may have been 9 or 10) on QNX4.0 and the compiler was
actually non compliant with regard to the precedence rules so using
parentheses... since that experience my little brqain is unable to
revert to remembering the rules.

 

[Keith Thompson]

A debugger of some description.

That sentence no verb.

Are you saying that debugging must always involve "a debugger of some
description"? If so, you're using the word "debugger in a much more
inclusive sense than I've ever seen. Please clarify.

If I happen to correct a flaw in a program by adding examining the
source code and adding temporary printf calls, I'm not using a
debugger (unless I *am* the debugger).

[...]

None of which has anything to do with why debugging is not a good thing.

Huh? Who ever said that debugging is not a good thing? Unless you're
using the word "debugging" specifically to mean using a source-level
debugger (such as gdb), then your statement makes no sense as far as I
can tell.

[...]

 

[Charlie Gordon]

Note : of course it is better to get it right first time. But in the
real world there will always be bugs.

2nd note : if a system crashes I can guarantee that i can debug it to
the point of the crash quicker than you can read and understand 500000
lines of C code and run it through in your head with all possible data
input and come to a guess at where it might crash .....

That may well be, but reading the 500000 lines will undoubtedly unearth
hundreds of other bugs, some of which would crash the system in even lesser
appropriate times.