What is a stack frame?

[Ian Collins]

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.

All to common in threaded applications on a multi-core machine
unfortunately..

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

Both the debugger and printfs are changing the normal timings of the
application.


I have only had to track one bug in a couple of decades where using the
debugger or adding printfs suppressed the bug. In the end, I caught it
with an ICE.

 

[lawrence.jones]

How did they program before debuggers then?

Ok, hands up: How many here have seen and actually used a core dump?

-Larry Jones

Mr. Subtlety drives home another point. -- Calvin

 

[Lew Pitcher]

jacob navia wrote:
[snip]

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)

[snip]

Having just retired from a 31-year job of doing exactly this ("debugging
progams of large size, written by others, without a debugger"), I must
admit that I got pretty good at doing the impossible.

--
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. ------

 

[Flash Gordon]

Ben Pfaff wrote, On 12/03/08 17:43:

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.

I've debugged programs larger than that on the basis of a fault
description when we did not have access to the hardware. I identified
that the SW fault was actually a HW problem causing memory corruption
with a couple of hours work examining printouts and using tools to
search the code. Actually catching it with the debugger to prove to the
HW engineer took a *lot* more work.

I've also debugged assembler of larger than 2000 lines based on
observable behaviour and reading the code (no debugger and hooking up
the logic analyser was a real pain and did not provide enough information.

Other times I will use a debugger when it is available. The really
advanced ones (especially ones that are use with In-Circuit Emulators)
can be incredibly useful and do things like "break on read before write"
to detect some accessing uninitialised data), break on a given location
being modified by any code other than a specific instruction (useful if
a variable is being corrupted by a buffer overflow or write through a
dangling/uninitialised pointer) and lots more.

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

I think they think that anyone who claims otherwise does not work.

 

[jacob navia]

Ben Pfaff wrote, On 12/03/08 17:43:

I've debugged programs larger than that on the basis of a fault
description when we did not have access to the hardware. I identified
that the SW fault was actually a HW problem causing memory corruption
with a couple of hours work examining printouts and using tools to
search the code. Actually catching it with the debugger to prove to the
HW engineer took a *lot* more work.

Of course, you had the whole program, algorithm, and field experience
with you in your head already loaded.

How about debugging my assembler output compiled in the
"just in time" compiler I wrote for a customer?

There, you would find that you have no clue, because you do
not know at all what the program is doing.

Neither do I, so, even if I wrote the compiler, debugging
that without a debugger is just hopeless!

I've also debugged assembler of larger than 2000 lines based on
observable behaviour and reading the code (no debugger and hooking up
the logic analyser was a real pain and did not provide enough information.

That can only work in incremental situations or very specific
situation when it is YOU that wrote all the code and you had
a great deal of experience with the program from countlessw
debugging sessions.

Other times I will use a debugger when it is available. The really
advanced ones (especially ones that are use with In-Circuit Emulators)
can be incredibly useful and do things like "break on read before write"
to detect some accessing uninitialised data),

That is useful. lcc-win fills the memory of the local variables at start
of a function with a special value that will provoke a trap in most
cases. This makes programs that "run with MSVC" trap sometimes, and I
get blamed.

break on a given location
being modified by any code other than a specific instruction

lcc-win's debuggers uses the HW breakpoints of the processor.
But they can't do that.


(useful if

a variable is being corrupted by a buffer overflow or write through a
dangling/uninitialised pointer) and lots more.


I think they think that anyone who claims otherwise does not work.

It will never work in the general case. It will work in very specific
situations when you know the code very well, and you understand
perfectly how the program works already.

 

[jacob navia]

jacob navia wrote:
[snip]

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)

[snip]

Having just retired from a 31-year job of doing exactly this ("debugging
progams of large size, written by others, without a debugger"), I must
admit that I got pretty good at doing the impossible.

No, you never did that. You wrote special purpose debuggers,
(printf statements output statements whatever), you used
your knowledge of the program/situation, etc to debug in
very specific situations. You can't go to the general case from there.

And I doubt that you never used a debugger, excuse me, unless you
provide a much more detailed explanation of how did you find the
bugs without one.

 

[jacob navia]

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

Why?!?!?!?

You didn't met Dan Pop.

In comp.std.c he once told the stunned audience that he never had a
crash of a program written by him.

The guys that say "I do not use a debugger" belong into the same
category of people.

 

[Lew Pitcher]

jacob navia wrote:
[snip]

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)

[snip]

Having just retired from a 31-year job of doing exactly this ("debugging
progams of large size, written by others, without a debugger"), I must
admit that I got pretty good at doing the impossible.

No, you never did that. You wrote special purpose debuggers,

No, Jacob. I /did/ do that. I /read/ programs. I /desk checked/ code. I drew
up truth tables and flow charts and Warnier Orr diagrams. I /walked
through/ code. And I did this on a daily basis for my employers. Online
banking code is considerably more than 2000 lines per program, as is
Customer Information Files, XML parsers, Cheque capture applications,
Documentary Letters of Credit applications and a host of others.

That is what a /professional/ does.

--
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. ------

 

[Flash Gordon]

jacob navia wrote, On 12/03/08 19:28:

Of course, you had the whole program, algorithm, and field experience
with you in your head already loaded.

I had never even looked at the code in question before. I probably new
as much about it as you know about the source code for Microsoft Visual C++.

How about debugging my assembler output compiled in the
"just in time" compiler I wrote for a customer?

How much will you pay me? I'm not cheap.

There, you would find that you have no clue, because you do
not know at all what the program is doing.

Not uncommon when you have never seen the code before.

Neither do I, so, even if I wrote the compiler, debugging
that without a debugger is just hopeless!
Depends.


That can only work in incremental situations or very specific
situation when it is YOU that wrote all the code and you had
a great deal of experience with the program from countlessw
debugging sessions.

To be more precise I wrote exactly NONE of that code and had never seen
it or the algorithms it implemented before. Shortly before doing this I
was sent on a course to learn the assembler language it was written in.
This project was my first real use of the language, and the people who
had done all of the previous work on the code had already left the company.

That is useful. lcc-win fills the memory of the local variables at start
of a function with a special value that will provoke a trap in most
cases. This makes programs that "run with MSVC" trap sometimes, and I
get blamed.

The systems I am thinking of are even more useful. They do not rely at
all on what the contents of the memory is and will work just as well if
you are reading an unsigned char which does not even have a trap
representation.

lcc-win's debuggers uses the HW breakpoints of the processor.
But they can't do that.

Well, I will admit that I spent 25000UKP (excluding VAT) of the
customers money on the kit, so I would expect it to have a few more
facilities than your debugger, gcc, the debugger in MS VC++ or any other
debugger I have ever used.

(useful if

It will never work in the general case. It will work in very specific
situations when you know the code very well, and you understand
perfectly how the program works already.

Like most programmers, a large amount of the code I have worked on was
not written by me, including several where I worked very successfully
without using a debugger. Even where I did write some of the code, I was
often one of many people, often including people who had left the
company before I ever looked at the software in question. I was also
often "dropped in it" by being given stuff where I did not even know the
application domain, and sometimes did not even know the language (Coral
66). I never did learn Coral 66, although I had to debug programs
written in it a few times.

I do use debuggers and agree they are useful. However I have not used
them on all project and have done a lot of debugging by reading
documentation (to find out what the code was intended to do and how it
was intended to do it) and reading code and looking at the output and
doing reasoning.

Probably the hardest system I ever had to debug used 20 processor cores
and was doing real-time video processing, and I could not stop the
incoming video data. I tried using the debuggers (I could make a break
on one processor core cause all of them to halt) but often had to give
up with the debuggers and just sit down with reams of printouts
scrawling all over them to work out what was going on. I could not use
the debuggers for much because the debugger breaking the code (or single
stepping) broke the pipeline and changed the behaviour of the code (the
code relied on the documented behaviour of the pileline).

 

[Flash Gordon]

Ian Collins wrote, On 12/03/08 18:17:

All to common in threaded applications on a multi-core machine
unfortunately..

I've had an set of ICEs which connected together and allowed you to
break all the processor cores nominally at the same time. A shame I only
had 4 machines running X (including one X terminal) to throw the 20
debugger windows (one per processor core) at.

Both the debugger and printfs are changing the normal timings of the
application.

Time to get the logic analyser out and ask a HW engineer to hook it up
for you. Yes, I have used logic analysers to debug code.

I have only had to track one bug in a couple of decades where using the
debugger or adding printfs suppressed the bug. In the end, I caught it
with an ICE.

I've had some problems with an event driven GUI application written in
Delphi where any attempt to break the program changed the relative
timings of the events (some generated by the program itself) and either
suppressed the bug or caused a different failure to occur instead. The
application now optionally logs the events of interest and when certain
functions are called and with what parameters.

 

[jacob navia]

jacob navia wrote:
[snip]
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)
[snip]

Having just retired from a 31-year job of doing exactly this ("debugging
progams of large size, written by others, without a debugger"), I must
admit that I got pretty good at doing the impossible.

No, you never did that. You wrote special purpose debuggers,

No, Jacob. I /did/ do that. I /read/ programs. I /desk checked/ code. I drew
up truth tables and flow charts and Warnier Orr diagrams. I /walked
through/ code. And I did this on a daily basis for my employers. Online
banking code is considerably more than 2000 lines per program, as is
Customer Information Files, XML parsers, Cheque capture applications,
Documentary Letters of Credit applications and a host of others.

That is what a /professional/ does.

Well I am an amateur then. Of course.
I do use debuggers. I desk check my programs as a matter of course,
but I know that you can't desk check everything, specially the
unexpected.

Bugs arise in places you do not expect them.

How can you know that library xyz is trashing your variable?

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

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

 

[Ben Bacarisse]

Ok, hands up: How many here have seen and actually used a core
dump?

If you mean when it was a dump of data stored by actual cores, then my
hand is up.

<totally off-topic>
As one of the "they" referred to...

My very first job was debugging programs written by scientists. There
was no debugger, and "printfs" (it was mostly FORTRAN, but you know
what I mean) were way too slow. You'd have to punch the extra cards
(in a nice contrasting colour) insert them into the deck and re-submit
the job. You'd get the output the next day, if the user's job quota
allowed it. That method was out.

Debugging was done by inspection of the code, the magic PSW, and
loader map. A core dump was a luxury reserved for people important
enough to get access to the terminal system that ran in the
afternoons.

The idea that a debugger (or a "virtual one" made up of print
statements) is required is extraordinary. They may be desirable, but
neither is required.

I was blown away when I used my first debugger (no source-level, just
poking about in code files and disassembled code) and again when
source-level debuggers came along, but I have regressed as the years
have passed. I won't say how far, because I won't be believed by the
key protagonists.
</totally off-topic>

 

[Ian Collins]

Ian Collins wrote, On 12/03/08 18:17:

Time to get the logic analyser out and ask a HW engineer to hook it up
for you. Yes, I have used logic analysers to debug code.

Last time I used a logic analyser, I found the problem was in the hardware!

 

[Richard Heathfield]

(e-mail address removed) said:

Ok, hands up: How many here have seen and actually used a core dump?

Count me in, darn you - I'd almost forgotten, and now look.

 

[Morris Dovey]

Ok, hands up: How many here have seen and actually used a core dump?

Another hand up.

 

[Morris Dovey]

Bugs arise in places you do not expect them.

This may be the essential difference between the way the two of
you approach debugging.

 

[Flash Gordon]

Ian Collins wrote, On 12/03/08 22:22:

Last time I used a logic analyser, I found the problem was in the hardware!

BTDTGTTS. Also had the logic analyser change the timings affecting the
behaviour of the hardware. Found some SW bugs with them as well.

 

[Nick Keighley]

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.

ditto.

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

 

[Nick Keighley]

How the hell can it NOT work for you?

trust me.

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

I'll probably abandon this as fruitless as we seem to be
in a dialogue of the deaf.

But one more try... If I know which path the code is goign to
follow I can put in approriate break points. If I don't
then I single step. That makes for an awful lot of single
stepping. This is slow and tedious. Why not *read the code*
work out where it's going and, well, go there?!

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

I'm *really* not doing this to wind you up. Note
more than one person is making similar claims.
Is it a conspiracy?

 

[Nick Keighley]

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

nope. 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!

I find this unlikely. The debugger is likely to disrupt
the RT nature of the problem.