"regulars" do not use debuggers

[Nick Keighley]

for me instead the debugger is a test;
every function has to pass the "test the first run" in the debugger
for see what going there (and always go wrong the first time)

and to me this is *the* primary way to waste time with a debugger.
If you want to test a function write a test. Then you can re-run
the test at any time for almost zero cost. And it will always
be the same test.


eg. me. I suspect most people do it from time to time. Sometimes
when somebody describes a fault to you in a program you are familar
with you can almost instantly diagnose the problem. "Darn I bet
the code doesn't check that the string isn't null!". And you look
at the code and lo, you are right.

not seem that to me. i can read well my code 10% like "Barry Schwarz"
because i write the sub language i know but i could to have some difficulty
to follow some C library function or the full C++ syntax

well I'm talking about code you are very familiar with. Obviously
in you aren't sure of the semantics of the constructs you are looking
at you'll have a hard time working out what the program is doing
(by definition really!). This comes with practice. And I'd rather
read a manual then single-step a debugger to learn the semantics
of a language! A debugger seems a *very* hit-and-miss way to learn a
programming language.

i not know how to use a debugger because someone theach me what to do;
but it is better to see what code does and how-where data is written
in the memory

I disagree. Some people who post on this ng agree with you.

this is wrong because it is possible one operation that you think write
on the data memory  000000000000000000000000000000000000000000000000000
write in memory     001111111000000000000001111111100000002222200000000

no it isn't wrong. He really did this. You are getting way
to chummy with the machine. I almost never care what addresses my
program
is using. I couldn't for instance tell you where the stack is for any
of
the programs I routinely modify and (sadly :-( ) debug.

sometime there is something has not "symptom" this day
but tomorrow can seg falut or give one wrong answer

If there are no symptoms there is no bug...

 

[Nick Keighley]

I disagree. Some people who post on this ng agree with you.



no it isn't wrong. He really did this. You are getting way
to chummy with the machine. I almost never care what addresses my
program is using.

had this wrong (again). You seem to be saying you expect the data
written to
memory to be all zeros but it is actually some other value. I still
find
this unlikely.

And I'm curious about your platform. It didn't know there were any 50-
trit
machines running (apart from the DS9k in Complete-Bastard mode).

I couldn't for instance tell you where the stack is for any
of the programs I routinely modify and (sadly :-(  ) debug.

<snip>

 

[Lew Pitcher]

What is a "SOC4"?

We drift far afield here

A S0C4 (System program-interruption-code 0C4) or "Addressing Exception"
happens when your program attempts to access an address (read or write)
outside of the memory allocated to the program. Think of it as a
wild-pointer dereference.

Can you explain what kind of error you can fix without a debugger?

All of them. A "production programmer" isn't given the chance to run a
debugger on a production problem. He's given the source code, a symbolic
dump of the abend, and (if the auditors agree), the data (I worked for a
bank, and this was *confidential* *financial* data, covered by privacy
laws, and not something we were always allowed to look at).

The symbolic dump was the most help; it showed the contents of static
variables (identified by the symbolic name used in the source code), the
contents of registers (including the PSW which stored the address of the
next sequential instruction, and all the condition-code bits), the contents
of all dynamic storage (the equivalent to C automatic storage, again
identified by program symbolic name), the contents of all GETMAINed memory
(C malloc()ed memory), the names, locations, and contents of each program
(contents expressed as a hex-dump of the machine instructions), etc.

From this dump, and the program listings, a competent programmer could
- establish the statement at which the abend occurred,
- establish what data the program was manipulating at the time,
- determine how the program arrived at that statement (the logic path),
- deduce the related program flow, and
- determine the logic or data error that cause the abend.

Now, having access to the source code (in a development library), the
programmer could then create an alternative program that bypassed or fixed
the problem, compile it (using the source code control system), and submit
it to be implemented as a "remedial fix" to the error. If the remedial was
accepted, the new program would be executed, using the original data, and
any alterations the programmer needed in order to bypass already-processed
data, and the output would be scrutinized for accuracy.

If everything passed, the rest of the jobstream would be permitted to
continue, and the programmer would go back to bed.


Why do so many people here (mostly people who haven't had a lot (a decade or
more) of programming experience) find it so unbelievable that a competent
programmer would not need a debugger?
--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[Chris Dollin]

Why do so many people here (mostly people who haven't had a lot (a decade or
more) of programming experience) find it so unbelievable that a competent
programmer would not need a debugger?

Because they (incorrectly) equate the statement "you don't need a debugger"
with the statement "debuggers are useless"?

 

[James Dow Allen]

All of them....

Many of the most subtle and hard-to-diagnose bugs are difficult to
solve *with* a debugger! Bugs that "dump core" due to divide
by zero or segmentation fault are usually quite easy to solve with
or without a debugger. Since none of us use uninitialized pointers
or free'd memory (right?), it's usually not hard to find the one
oversight.

My very first Connect-Four solver had a bug: a cache slot was reserved
for a partially-solved position, as solution continued the slot was
purged by a sort-of least-recently-used algorithm and, although I
*think*
I was aware of the problem, there was a special case where the now-
obsolete pointer ended up being used. Core didn't dump, or anything
like that; the solver continued happily along, but thinking that a
lost subposition was actually won! I wouldn't know *how* to detect,
let alone solve, this problem with a debugger. Instead I did what I
should have done all along: careful "walk-through."

These days, I get more Seg-Faults than I should. I usually type
'gdb' just to notice which function failed and, although I tend to use
longish functions, it isn't hard to find the faulty pointer
generation. (I've added "-Wall" to my makefiles; this probably
avoids many trivial bugs.)

Why do so many people here (mostly people who haven't had a lot (a decade or
more) of programming experience) find it so unbelievable that a competent
programmer would not need a debugger?

Oops! I've had a decade (or more) of *retirement* without serious
programming. In the good old days I sometimes sat at the console
of a million-dollar mainframe, dialling breakpoints into the
switches. That was fun!

James D. Allen

 

[Rui Maciel]

Yes of course. I use a debugger too. But apparently here there is a
group of people that do not use debuggers!!!

Could you please explain exactly what is your problem with the idea that some people don't use debuggers?

Of course the software they write doesn't have any bugs!

It appears that you haven't been paying attention to this very thread.



Rui Maciel

 

[Moi]

Mr Richard harter says in the thread

Modifying the arguments to a function is a bad idea (message id


Mr "pete" ([email protected]) replies:


This proves that the "regulars" are a highly sophisticated elite.
Probably they do not debug their programs (of course they will tell us
that they do not have bugs) etc etc.

Debuggers are like hospitals.

You don't want to spend the rest of your life in a hospital.
Once you are out: draw your conclusions and get on with your life.

AvK