12

Is there a complete resource for debugging in Delphi that instructs on how to use all the IDE debugging tools? There used to be a guide from Marco Cantù but it was updated to Delphi 5 if I am not wrong.

May you please redirect me to a complete resource updated at least to D2009 (better if XE).

5
  • 3
    The most complete resource is the internet at large, but that is a bit broad. Is there anything specific you are looking for? Commented Oct 22, 2010 at 8:12
  • I agree with Jeroen. This is a very general question, where you can't expect a more specific answer than "the internet" (which is indeed the ultimate resource). ;-) Commented Oct 22, 2010 at 8:16
  • 1
    I mean is there a complete instruction, with overview of all the features. Let's say "a kind of eBook". Commented Oct 22, 2010 at 8:44
  • Take a look at “Delphi in all its glory” especially Part II. A good part of the book discusses debugging techniques, including debugging packages, remote debugging, compiler settings for debugging mode, bug logging and reporting (madShi & Eureka), etc. But debugging (even though it takes up a good part of the book) is touched only “accidentally”. The main topic of the book is how to write code in such a way that you don't have to debug (bug prevention). I think this is the wise approach to debugging :) Commented Jul 3, 2024 at 7:41
  • also see: stackoverflow.com/a/78155697/46207 Commented Jul 23 at 9:53

5 Answers 5

8

The debugging resource PDF didn't mention my favorite debugging technique:

Let's say you wanted to break if a certain, complex, only-available at runtime condition was met.

You could say

if <MyExpressionA> then
asm
  int 3; // Enter CPU Debugger
end;

Or you could say

if not <MyExpressionB> then
asm
  int 3; // Enter CPU Debugger
end;

Where ExpressionA is something you NEVER expect to be true (i.e., if it's true, it signals an anomalous condition), OR where ExpressionB is something you ALWAYS expect to be true (i.e., if it's false, it signals an anomalous condition).

Remember that either expression can contain multiple function calls -- if you need them.

You could put them inside of a block, inside of {$IFDEF DEBUG}, like this:

procedure MyProcedure;
var X: Integer;
begin
  X := GetTheAnswerToLifeTheUniverseAndEverything();

  {$IFDEF DEBUG}
  if X <> 42 then // Highly contrived example
  asm
    int 3; // Enter CPU Debugger -- Press F8 when here to step back into source...
  end;
  {$ENDIF}

  // More code here...

end;

You can also use

ASSERT(Expression, "Message"); ASSERT(not Expression, "Message");

To make sure things function as expected in your code.

If ASSERTs are enabled in the IDE and an ASSERT fails -- the ASSERT will create an exception, which will unwind the stack to the last exception handler for its type...

Using my int3 method -- you get immediately into the CPU debugger -- where, if you hit F8 (step over), you'll step to the next line of code -- you can inspect variables, see the whole call stack, and even continue stepping in your code...

Sign up to request clarification or add additional context in comments.

3 Comments

Great tip! Unfortunately it is hidden here in this question.
Nice. But note that is you are not under IDE, your app will crash if it steps into the int3!
Instead I use an empty procedure called EmptyDummy with a breakpoint on it. if x <> 42 then EmptyDummy;
6

IMO the official documentation on debugging is comprehensive: Debugging Applications and Debugging Applications. AFAICS the two sites have similar content but the latter may be more up to date.

I also would like to note Warren Postma's tutorial on Remote Debugging which has helped me start at no time.

1 Comment

Thanks for the tutorial link, it is faster to read than the documentation.
5

Internet is your friend, here are two links about debugging

Delphi - Debugging techniques

[PDF] http://www.scip.be/ScipViewFile.php?Page=ArticlesDelphi11

The content in there is still very relevant

Comments

4

Also invest some time in an exception handling framework such as:

Has all the good stuff in there like stack traces, line numbers etc.

Comments

2

I'd like to complement Peter Sherman's excellent response:

My favorite debugging technique is

if <MyExpression> then
  asm nop end;

This code does basically nothing and has no influence on running performance. It is a no-op. However you can put regular breakpoints on that "asm" line and it will work just like any other breakpoint. Whoever have tried conditional breakpoints (especially those inside loops) know that it can take forever for the debugger to evaluate the breakpoint condition and it will become a nightmare to run multiple debugging sessions. In the above case, it runs on full speed and have no other side effects.

A side note: The asm block can only be used with x86 compilers.

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.