Re: Delphi 6 Compiler and Hyper Threading BUG?!

From: Bruce Roberts (ber_at_bounceitattcanada.xnet)
Date: 02/10/04 

Date: Tue, 10 Feb 2004 15:17:22 -0500

"J French" <erewhon@nowhere.com> wrote in message
news:40291c1e.104180252@news.btclick.com...

> I propose a new entry to the FAQ
> - 'How to Debug an App'

Good idea for someone's FAQ. But not, IMO, the mini-FAQ.

>
> (but I am too idle to write it )

Debugging An Application
-------------------------------------

0. Make sure that what you are observing is, in fact, a bug. In complex
applications apparently buggy behavior can often be the logical result of
some other action. It may even be explicitly designed in. With the correct
context and understanding the action may even be desired.

1. 99.999%* of the time the bug will be in your application, not the
compiler or o/s.

2. 96% of the time the bug will be a problem in code you wrote. (25% of the
time the problem will likely be because you are not using a 3rd party
component properly. 35% of the time it will be because you are not using a
VCL component or Win API call properly. If one is new to the language, 15%
of the time the problem will be in not fully understanding the language
constructs being used.) 3.5% of the time it is likely to be in the data you
are using to test. In the remaining 0.499% (depending on the quality of 3rd
party components that you use this might be as high as 20%), the probable
culprit is a 3rd party component or combination of components.

3. The quickest way to make a simple problem impossible to solve is to
assume. Make no assumptions other than that the code isn't working as
expected. This is important enough to repeat. Make no assumptions. As I
said, make no assumptions.

4. In most cases you can solve the problem most quickly by inserting a few
Assert statements and perhaps one or two ShowMessage calls. Using the
debugger first is rarely a good idea since it focuses you on the low-level.
Remember, you are more often than not looking for a problem in your own
logic and data.
    - Look for simple mistakes first. Things like similar identifiers being
switched, forgotten initializations, unexpected values being encountered,
the wrong variable being referenced.
    - Then look for actual logical errors. IOW will the code ever do what
you think it will do? Will it do it in all cases?
    - Then make sure that event handlers are being executed in the sequence
and at the time you expect them to be. Often a bug is the result of the
programmer not really understanding the interaction of his code and the
components it uses. Don't assume first that another's component is at fault.
If it isn't behaving the way one expects one should first suspect that one's
expectations are wrong.
    - Use Assert to verify that the assumptions made in the code are correct
(as opposed to the assumptions that you haven't made). For example, a
routine may assume that a particular parameter is not nil. Use Assert to
insure this.
    - Use ShowMessage to verify that data values are in an acceptable range
and that the program is executing routines the way you think it should. For
example, upon return from a routine a caller might expect a valid machine
name. Use ShowMessage to display the retuned value.

5. When a problem is very difficult to solve, simplify. Lift the offending
piece of code out of the app and work with a small test. If the test doesn't
contain the error then one is not likely looking in the right place.

* All percentages are taken out of thin air with some influence from the
author's personal experience.

Relevant Pages

  • Re: slurping in binary data
    ... You seem to doubt you have a bug. ... console window in Windows), so there's no problem using printfto ... My own most fundamental rule for debugging programs is ... with a series of premises assumed to ...
    (comp.lang.c)
  • Re: kernel BUG at drivers/ide/ide-disk.c:187 (2.6.31)
    ... Thus when the unknown block layer request is encountered the best thing ... Yes, but if you BUG() in this kind of location, the chance of getting ... the debugging information from the user can be close to zero. ... I really do not have to work on IDE ...
    (Linux-Kernel)
  • Re: Article - "An introduction to Delta Debugging"
    ... want to see where the crash happens, then I can use the thing that knows it: ... Tools like madExcept have cut my bug hunting time from hours ... And Delta Debugging covering source code? ...
    (borland.public.delphi.non-technical)
  • Re: Debugging C++ templates with gdb
    ... > would of course execute the machine code in order, ... > code no longer maps to the C code lines in ascending order. ... > debugging. ... knowing the approximate location of the bug ...
    (comp.os.linux.development.apps)
  • Re: Deprecating reload() ???
    ... VC/VB, while debugging a program, it is very often to get into this ... insight into the source and nature of the bug. ... Without interactive programming's edit-and-continue feature, ... you don't restart ...
    (comp.lang.python)