What debugging methods are available? 
Author Message
 What debugging methods are available?

This is rather general subject. I am a beginner and I have been
learning C and C++ from books, by reading FAQ, by scanning usenet
newsgroups and, sometimes, contacting other programmers. I have
written a number of programs, which perform as I expected them to
do. Are they well written, are they efficient and foolproof? I do
not know it and might not know it for long.

What I feel that I need to know, are methods of debugging. My
compiler reports to me errors, I have committed, specifying
mostly nature of a problem. Then I check the syntax, read again
function descriptions, make modifications and test the program
repeatedly. Eventually, I will find a solution, but might not
know a real cause of my error. Specially, I would like to observe
the "mechanism" of memory allocation and declaration of pointers.
I know that for every malloc() I should have the corresponding
free() function. But if I allocate memory in a function, which I
enter repeatedly, then what? Or, if I open a file in a function,
I should close it, but has it to be closed in that function?

One thing is to follow blindly the language syntax and other do's
and don't's commanded in the manuals, another is to understand
what really happens. And I want to learn the latter.

I was checking one of my programs by using a coreleft() function.
During exercising it, I noticed that I was constantly loosing RAM
memory (memory leak). What was wrong? Everything seemed to be so
well written! Well, back to the square one. But what are other
diagnostic tools to see program operation "behind the screen" and
to help finding the problem? Maybe a core dump?

Andrew

 ===============================================
 Andrew M. Kukla        Toronto, Ontario, Canada

 ===============================================



Wed, 23 Aug 2000 03:00:00 GMT  
 What debugging methods are available?

: This is rather general subject. I am a beginner and I have been
: learning C and C++ from books, by reading FAQ, by scanning usenet
: newsgroups and, sometimes, contacting other programmers. I have
: written a number of programs, which perform as I expected them to
: do. Are they well written, are they efficient and foolproof? I do
: not know it and might not know it for long.
[...]
: I was checking one of my programs by using a coreleft() function.
: During exercising it, I noticed that I was constantly loosing RAM
: memory (memory leak). What was wrong? Everything seemed to be so
: well written! Well, back to the square one. But what are other
: diagnostic tools to see program operation "behind the screen" and
: to help finding the problem? Maybe a core dump?

Coredumps and postmortem (static) de{*filter*}s are one way to find things,
but they are a bit limited.  A modern compiler will often have some sort
of windowed de{*filter*} included, where you can step through code and watch
variables change.  This won't help with efficiency, you need profiling
tools (also part of a compiler suite) for that, but it will help with
correctness.  'Well-written' comes from reading a lot of code, and seeing
what styles you like and what styles are recommended.  'Foolproof' comes
from having other users test your programs; and is quite tricky.
"The trouble with making things foolproof is that fools are so ingenious".

There's quite a good book by R Ward called 'Debugging C', by Que, which
summarises some of the simpler debugging techniques.  I don't know if
it's still in print.  But the best approach is to find a compiler that
has a good GUI interface, and a powerful de{*filter*} - try using your
friends compilers and see which one you like best.

Post-compilation there are a number of program testing techniques which
have a whole literature of their own; generally for any major program
you need to build a suite of test programs alongside the main program,
so that changes don't inadvertently re-introduce bugs.

Will



Wed, 23 Aug 2000 03:00:00 GMT  
 What debugging methods are available?


Quote:

>This is rather general subject. I am a beginner and I have been
>learning C and C++ from books, by reading FAQ, by scanning usenet
>newsgroups and, sometimes, contacting other programmers.

... who almost certainly hate you now, even though you may not realize it.
Few things are more  annoying in a programmer's life than being bothered by
some newbie who won't pick up an introductory text and reference manual,
and perhaps take courses.

Quote:
>I have
>written a number of programs, which perform as I expected them to
>do. Are they well written, are they efficient and foolproof? I do
>not know it and might not know it for long.

>What I feel that I need to know, are methods of debugging. My
>compiler reports to me errors, I have committed, specifying
>mostly nature of a problem. Then I check the syntax, read again
>function descriptions, make modifications and test the program
>repeatedly. Eventually, I will find a solution, but might not
>know a real cause of my error.

Compiler errors are just the tip of the iceberg. A program which
passes the compiler constraint checks may be far from correct.
When you become an experienced programmer, you will find compiler
errors infrequent, and trivial to fix.

The checks required by the C language are quite trivial, and make it easy for
an incorrect nor non-portable program to be compiled with no compiler
diagnostics at all.

Quote:
>the "mechanism" of memory allocation and declaration of pointers.
>I know that for every malloc() I should have the corresponding
>free() function. But if I allocate memory in a function, which I
>enter repeatedly, then what?

Then you must ensure that all your pointers are reachable because
the are connected in a dynamic data structure such as a tree, linked
list or what have you, which can be traversed to discover all of the
pointers that were ever allocated. Whatever you do, you must somehow keep
track of the pointers to all allocated objects, because such objects
have no name and can be reached only by their pointer.

Quote:
>Or, if I open a file in a function,
>I should close it, but has it to be closed in that function?

No, a stream remains open until you close it. You can communicate the FILE *
pointer throughout your program.

Quote:
>One thing is to follow blindly the language syntax and other do's
>and don't's commanded in the manuals, another is to understand
>what really happens. And I want to learn the latter.

>I was checking one of my programs by using a coreleft() function.

Coreleft isn't a standard C function, and isn't available outside of the
DOS/Windows environment. It's also not a reliable detector of memory leaks,
because the free() function does not necessarily return memory to the system.
Many implementations of free() simply put the unused blocks into free lists
so that they can be used again. Thus the process appears to be leaking
memory until it reaches a steady state when all of its allocation requests
can be satisfied using previously freed memory.

Quote:
>During exercising it, I noticed that I was constantly loosing RAM
>memory (memory leak). What was wrong? Everything seemed to be so
>well written! Well, back to the square one. But what are other
>diagnostic tools to see program operation "behind the screen" and
>to help finding the problem? Maybe a core dump?

The best tools are printf(), assert(), and a compiler with its full
gamut of diagnostics turned on.  When these fail you, you may shamefully rely
on others, such as source-level interactive de{*filter*}s, bounds checkers, malloc
de{*filter*}s, etc.

If you constantly depend on de{*filter*}s, you aren't a true programmer.

There won't always be good debugging tools for every situation. Right now I'm
working on some multi-threaded code in an environment that does not support
interactive debugging of threaded programs. I can't even tell, post mortem,
which thread triggered a fault and in what line of code it happened.  I must
completely rely on the diagnostic output from debugging statements of the
program, assertion violations, and the discipline of thorough code inspection.
I've been able to find some defects only by careful reasoning through the
program logic.

Sure, poor environment you may say. But every environment starts out poor
until someone develops the tools.



Fri, 25 Aug 2000 03:00:00 GMT  
 What debugging methods are available?

Quote:



> >This is rather general subject. I am a beginner and I have been
> >learning C and C++ from books, by reading FAQ, by scanning usenet
> >newsgroups and, sometimes, contacting other programmers.

> ... who almost certainly hate you now, even though you may not realize it.
> Few things are more  annoying in a programmer's life than being bothered by
> some newbie who won't pick up an introductory text and reference manual,
> and perhaps take courses.

Hi Kaz,

I really have to object to this although the rest of your post is okay
(sorry Wilms, I take  this one on ;-> ). Here we have a case of a
self-proclaimed newbie who states he has read the FAQ, read some books,
lurked around on the usenet and __SOMETIMES__ contacted other
programmers.

What more could c.l.c wish from a newbie?

And now you suggest his helpfull mates probably hate him now...

Now, imagine young Andrew. A solitary and introvert wallflower who was
fascinated by the wonderfull art of programming. He could be somebody,
he could be a _programmer_. While other kids were making friends and
playing after school he studied C (good choice) even though he's only 9
years old. Being the only child and having no friends he turns to the
internet to talk to other programmers. At first only lurking around and
gasping in awe at the guru's in c.l.c he picks a favourit, an idol he
could worship: Kaz Kylheku. Now he's something: better than Peter
Seebach, Chris Torek or Steve Summit, he's _the_Man_.

He's going through a phase of uncertainty: sure, he now has mastered the
semantics and syntax but he wonders if he doesn't forget something, he
doubts whether the code which is generated really is the code he
intended and after some days of gathering courage and re-reading the faq
to avoid flames he takes the big leap: he posts a question to c.l.c

Oh! Glory! He sees his idol, the master of masters, the king of kings,
the concering lion of Judah: IOW Kaz Kylheku has taken some of his
precious time to answer his unworthy question.

Trembling, he reads the answer....

Well.. he never got past "who almost certainly hate you now". He now
acknowledged what he had always feared. He was too much on this
world.... His idol had turned him down, nobody liked him. He went down
to the ba{*filter*}t to get his late father's shotgun (oh yes: his mother
died at birth as well, he was raised by his evil aunt). He knew what to
do.... It took his relatives 6 days to realize he was missing....

Ah! Such a loss. He could have mastered programming and transcended his
mortal existence. He could have been someone helping out others and
perhaps even being admired.

Okay Kaz, now you've seen what you've done. Hey Kaz? Don't do that Kaz!
Where did you get that gun from anyway? You can't redeem yourself if
you're dead, Kaz???? BANGBANG!!! No!!!!

Shit... He also will be missed



Fri, 25 Aug 2000 03:00:00 GMT  
 What debugging methods are available?

Quote:



>>During exercising it, I noticed that I was constantly loosing RAM
>>memory (memory leak). What was wrong? Everything seemed to be so
>>well written! Well, back to the square one. But what are other
>>diagnostic tools to see program operation "behind the screen" and
>>to help finding the problem? Maybe a core dump?

Kaz provides excellent advice.  Especially:

Quote:
>The best tools are printf(), assert(), and a compiler with its
>full gamut of diagnostics turned on.  When these fail you, you may
>shamefully rely on others, such as source-level interactive de{*filter*}s,
>bounds checkers, malloc de{*filter*}s, etc.

But the following sentence

Quote:
>If you constantly depend on de{*filter*}s, you aren't a true programmer.

Should be taken with a grain of salt.  I will freely admit that I
often feel that way too, but I recognize it as a bias that has no
basis in fact.  It deosn't matter what tools you use to debug your
code, as long as you approach it logically with a well thought out
process.  It is the process you use in debugging that will lead to
success and this is orthogonal to the tool that you use.

Quote:
>There won't always be good debugging tools for every situation. Right
>now I'm working on some multi-threaded code in an environment that does
>not support interactive debugging of threaded programs. I can't even
>tell, post mortem, which thread triggered a fault and in what line of
>code it happened.  I must completely rely on the diagnostic output from
>debugging statements of the program, assertion violations, and the
>discipline of thorough code inspection.  I've been able to find some
>defects only by careful reasoning through the program logic.

Thus, if you have always depended upon using a de{*filter*}, but have
always used a debugging process, the process still applies when you
are placed in an environment without your de{*filter*}. The lesson is that
a well thought out debugging process can be applied to whatever tools
are available at hand.

--

http://www.*-*-*.com/ ~jxh/        Washington University in Saint Louis

Quote:
>>>>>>>>>>>>> I use *SpamBeGone* <URL: http://www.*-*-*.com/ ;



Fri, 25 Aug 2000 03:00:00 GMT  
 What debugging methods are available?



: >
: >This is rather general subject. I am a beginner and I have been
: >learning C and C++ from books, by reading FAQ, by scanning usenet
: >newsgroups and, sometimes, contacting other programmers.

: ... who almost certainly hate you now, even though you may not realize it.
: Few things are more  annoying in a programmer's life than being bothered by
: some newbie who won't pick up an introductory text and reference manual,
: and perhaps take courses.

Well, I can think of a lot of things more annoying than that, to be
honest.  If it's email, and simple, and I've time, I'll answer it.
If it's polite, and I don't have time, I'll say so.  If it's rude,
I'll delete it.  No-one's mailbombed me with queries yet...

He's said that he's learning C from books and by reading the FAQ;
without time and money and available courses, that's all you can do.
And his question here, about debugging, was actually quite an
interesting one.  I don't think that I'd have acted differently in
his place.

Will



Fri, 25 Aug 2000 03:00:00 GMT  
 What debugging methods are available?

Quote:




>: >
>: >This is rather general subject. I am a beginner and I have been
>: >learning C and C++ from books, by reading FAQ, by scanning usenet
>: >newsgroups and, sometimes, contacting other programmers.

>: ... who almost certainly hate you now, even though you may not realize it.
>: Few things are more  annoying in a programmer's life than being bothered by
>: some newbie who won't pick up an introductory text and reference manual,
>: and perhaps take courses.

>Well, I can think of a lot of things more annoying than that, to be
>honest.  If it's email, and simple, and I've time, I'll answer it.

Yes. E-mail is the least annoying, because you can answer it with finality
and on your own time. Or choose to ignore it! :)

Quote:
>If it's polite, and I don't have time, I'll say so.  If it's rude,
>I'll delete it.  No-one's mailbombed me with queries yet...

What if they phoned you? :P

Quote:
>He's said that he's learning C from books and by reading the FAQ;
>without time and money and available courses, that's all you can do.

Oh sure, from *my* personal point of view, he's a model newbie! :))


Fri, 25 Aug 2000 03:00:00 GMT  
 What debugging methods are available?



| >
| >This is rather general subject. I am a beginner and I have been
| >learning C and C++ from books, by reading FAQ, by scanning usenet
| >newsgroups and, sometimes, contacting other programmers.
|
| ... who almost certainly hate you now, even though you may not realize it.
| Few things are more  annoying in a programmer's life than being bothered by
| some newbie who won't pick up an introductory text and reference manual,
| and perhaps take courses.
|
Let me explain few things. I am surrounded by books (manuals,
tutorials and references) about C and C++ languages (total
"thickness" of them is 12.5 inches) not in a library, but at
home. These books, which I have purchased, I am reading,
rereading and reviewing. Despite of this honest work, I may be
missing some diagnostic techniques that some of you were taught
by your teachers in the past. And I will never know it, unless I
ask to review what I have already been doing.

Maybe, there is a function to test a stack, or to dump a content
of some part of memory, or some other test that could display
"action behind the screen". Maybe, there is a RFD function
(Return From Disaster) that will be helpful. Or, maybe, I should
not look into that part, but continue these techniques, what I
already know. I am asking these questions when my compiler claims
no errors. I use logic and always want to understand mechanism of
happenings rather, then be blind follower of syntax.

I am not such a "newbie" as you may think. My first contacts with
computer language (ALGOL) goes to sixties. And I am familiar with
"machine code" and assembly programming. You hate me, it's your
choice; however, you had a better option to ignore me. I did not
bother you and I did not deserve your response. Oh, well.

Kaz, with reference to the rest of your letter (that is enclosed
here and below) I appreciate your effort responding to my
questions. You have explained to me a number of things up to the
point ensuring that I am, probably, on right track. Thank you.

| >I have
| >written a number of programs, which perform as I expected them to
| >do. Are they well written, are they efficient and foolproof? I do
| >not know it and might not know it for long.
| >
| >What I feel that I need to know, are methods of debugging. My
| >compiler reports to me errors, I have committed, specifying
| >mostly nature of a problem. Then I check the syntax, read again
| >function descriptions, make modifications and test the program
| >repeatedly. Eventually, I will find a solution, but might not
| >know a real cause of my error.
|
| Compiler errors are just the tip of the iceberg. A program which
| passes the compiler constraint checks may be far from correct.
| When you become an experienced programmer, you will find compiler
| errors infrequent, and trivial to fix.
|
| The checks required by the C language are quite trivial, and make it easy for
| an incorrect nor non-portable program to be compiled with no compiler
| diagnostics at all.
|
| >the "mechanism" of memory allocation and declaration of pointers.
| >I know that for every malloc() I should have the corresponding
| >free() function. But if I allocate memory in a function, which I
| >enter repeatedly, then what?
|
| Then you must ensure that all your pointers are reachable because
| the are connected in a dynamic data structure such as a tree, linked
| list or what have you, which can be traversed to discover all of the
| pointers that were ever allocated. Whatever you do, you must somehow keep
| track of the pointers to all allocated objects, because such objects
| have no name and can be reached only by their pointer.
|
| >Or, if I open a file in a function,
| >I should close it, but has it to be closed in that function?
|
| No, a stream remains open until you close it. You can communicate the FILE *
| pointer throughout your program.
|
| >One thing is to follow blindly the language syntax and other do's
| >and don't's commanded in the manuals, another is to understand
| >what really happens. And I want to learn the latter.
| >
| >I was checking one of my programs by using a coreleft() function.
|
| Coreleft isn't a standard C function, and isn't available outside of the
| DOS/Windows environment. It's also not a reliable detector of memory leaks,
| because the free() function does not necessarily return memory to the system.
| Many implementations of free() simply put the unused blocks into free lists
| so that they can be used again. Thus the process appears to be leaking
| memory until it reaches a steady state when all of its allocation requests
| can be satisfied using previously freed memory.
|
| >During exercising it, I noticed that I was constantly loosing RAM
| >memory (memory leak). What was wrong? Everything seemed to be so
| >well written! Well, back to the square one. But what are other
| >diagnostic tools to see program operation "behind the screen" and
| >to help finding the problem? Maybe a core dump?
|
| The best tools are printf(), assert(), and a compiler with its full
| gamut of diagnostics turned on.  When these fail you, you may shamefully rely
| on others, such as source-level interactive de{*filter*}s, bounds checkers, malloc
| de{*filter*}s, etc.
|
| If you constantly depend on de{*filter*}s, you aren't a true programmer.
|
| There won't always be good debugging tools for every situation. Right now I'm
| working on some multi-threaded code in an environment that does not support
| interactive debugging of threaded programs. I can't even tell, post mortem,
| which thread triggered a fault and in what line of code it happened.  I must
| completely rely on the diagnostic output from debugging statements of the
| program, assertion violations, and the discipline of thorough code inspection.
| I've been able to find some defects only by careful reasoning through the
| program logic.
|
| Sure, poor environment you may say. But every environment starts out poor
| until someone develops the tools.

 ===============================================
 Andrew M. Kukla        Toronto, Ontario, Canada

 ===============================================



Sat, 26 Aug 2000 03:00:00 GMT  
 What debugging methods are available?


[excellent comments by Kaz elided]

Quote:
>>One thing is to follow blindly the language syntax and other do's
>>and don't's commanded in the manuals, another is to understand
>>what really happens. And I want to learn the latter.

   I recommend reading Keonig's _C Traps and Pitfalls_ and van der Linden's
_Expect C Programming: Deep C Secrets_ (since you wrote elsewhere that you
are interested in books).

[...]

Quote:
>The best tools are printf(), assert(), and a compiler with its full
>gamut of diagnostics turned on.  When these fail you, you may shamefully rely
>on others, such as source-level interactive de{*filter*}s, bounds checkers, malloc
>de{*filter*}s, etc.

    I know that we are discussing finding memory leaks, but I still think
that a lint could help.  Lints do more (and sometimes better) checking
than any compiler with its full gamut of diagnostics turned on.   Although
I have not used it I have heard that LC lint is good (and it is free).
--



Tue, 29 Aug 2000 03:00:00 GMT  
 What debugging methods are available?

[snip]

Quote:
>What is "LC lint", please?

http://larch-www.lcs.mit.edu:8001/larch/lclint/links.html
--
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ ftp: ftp://rtfm.mit.edu, C-FAQ Book: ISBN 0-201-84519-9
Try "C Programming: A Modern Approach" ISBN 0-393-96945-2
Want Software?  Algorithms?  Pubs? http://www.infoseek.com


Tue, 29 Aug 2000 03:00:00 GMT  
 What debugging methods are available?

[...]
|    I recommend reading Keonig's _C Traps and Pitfalls_ and van der Linden's
| _Expect C Programming: Deep C Secrets_ (since you wrote elsewhere that you
| are interested in books).

Thanks for info.

[...]
|     I know that we are discussing finding memory leaks, but I still think
| that a lint could help.  Lints do more (and sometimes better) checking
| than any compiler with its full gamut of diagnostics turned on.   Although
| I have not used it I have heard that LC lint is good (and it is free).

What is "LC lint", please?

Andrew

 ===============================================
 Andrew M. Kukla        Toronto, Ontario, Canada

 ===============================================



Wed, 30 Aug 2000 03:00:00 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. Aggregated methods not available in VBSCRIPT

2. class methods that have parameters available in dll?

3. GCC support for DWARF debugging info format now available

4. Debugging Information Format specification available for review

5. ANN: Latest debugging tools available from Entrek

6. I am new to programming and am lost

7. Executing methods while debugging

8. How to disable CString methods debugging?

9. ActiveX control returns success from method when compiled in Debug mode but not in release

10. HELP! Seeking debugging methods on memory allocation errors

11. How to debug an Input Method dll

12. Debug.print method

 

 
Powered by phpBB® Forum Software