How best to debug Delphi using the IDE and/or FOSS?

Question

I see the following means of debugging and wonder if there are others or which FOSS tools a small company can use (we don't do much Windows programming).

1 Debug in the IDE, by setting breakpoints, using watches, etc

2 Debug in the IDE, by using the Event Log
I got some good info from this page and tweaked it to add timestamps and indent/outdent on procedure call/return, so that I can see nested calls more quickly. Does anyone know of anything better ?

3 Using a profiler

4 Any others?
Such as MadExcept, etc?

(I am currently using Delphi 7)

Answer 1

The Delphi integrated debugger is powerful enough, even in Delphi 7, to handle most debugging tasks. It can also debug an application remotely. Anyway, there are situations where you may need to track different kind of issue:

1. To check for memory leaks, you can switch to a memory manager like FastMM4 which has good memory leak reporting. Profilers like AQTime have also memory allocation profilers to identify such kind of issues.
2. To investigate performance problems, you need a performance profiler. There are sampling profilers (less invasive, although may be less precise) and standard profilers (AQTime again, not cheap but very good, and others).
3. To trace exception, especially on deployed applications, you may need tools like JCL/JVCL (free), MadExcept or EurekaLog or SmartInspect
4. To obtain a log of what the application does, you can use OutputDebugString() and the IDE event viewer, or the DebugView standalone application. There are also dedicated tools like SmartInspect.
5. You can also convert Delphi 7 .map files to .dbg files and use an external debugger as the WinSDK WinDbg, and look at application calls in tools like ProcessExplorer

Some debugging tools may also offer features like code coverage checks (which code was actually executed, and which was never), platform compliance (check API calls are supported by a given platform), resources use and so on, but may be useful for larger developments.

Answer 2

Delphi 7's IDE is pretty good to start with, only look at 3rd party tools if you run into something you can't fix with what you've got:

• It's error messages are informative and not excessively verbose.
• The debugger is pretty good, you've got lots of options for inspecting variables, brakepoints, conditional brakepoints, data brakepoints, address brakepoint, module load brakepoint. It's call-stack view is good, it has some support for multi-threaded debugging.
• Good step-by-step execution, step into, step over, run until return, etc.

3rd party tools help when you need to diagnose a problem on the client's computer (you have no Delphi IDE on the client's computer). If you can get the problem to manifest on your computer you get away with the IDE alone, no need for any addition, free or payed for.

• Profiler: That's not a debugging tool. You use an profiler when you need to find bottlenecks in your application, or you need to do some speed optimizations.
• Logging 3rd party frameworks: The good ones are not cheap, and you can do minimal logging without a tool (even ShowMessage works some times).
• MadExcept, other tools that log exceptions: They usually require debugging information to be present in the EXE, and that's not a good idea because it makes the program slower AND it easier to hack. Again, if you can get the exception on your machine, you don't need the logger.

I'm not saying 3rd party debugging aids are not useful: they are, but I'd wait until I can clearly see the benefit of any tool before I commit to it. And in my opinion there's no such thing as free software: Even the software you don't pay for requires time to learn how to use it and requires changes to your programs and workflow.

Answer 3

For the bigger work, there is AQTime.

A cheaper solution for selected code is running it through Free Pascal (with the "randomize local variables option") and run it through valgrind. I've validated most my streaming code (which heavily has backwards compat constructs) that way.

Another such interesting switch is -CR, verify object method call. It basically turns every

TXXX(something).callsomething 

into

if something is txx then 
   TXXX(something).callsomething 
else
   raise some exception;

Specially in code with complex trees this can give some precious information.

Normal Pascal language checking (Range, I/O, Overflow, sTack aka -Criot) can be useful too, and is also available in Delphi.

Some range check errors (often loop bounderies) that can be detected statically, will result in compile errors in (beta) FPC 3.0.x+.

Answer 4

You can try the "Process Stack Viewer" of my (open source) sampling profiler: http://code.google.com/p/asmprofiler/wiki/ProcessStackViewer
(you need some debug info: a .map or .jdbg file)

You can watch the stack (also the raw stack, with "false positives" but useful when normal stack walking is not possible) of all threads, and do some simple sampling profiling.

Note: My (older) instrumenting profiler does exact profiling, is on the same site.

Answer 5

Not sure why you would want to upgrade to debug a problem. Yes the newer IDE's provide more features to help you debug something, but taking into consideration your previous question on how to debug your program when it hangs, I'd sooner suggest a good logging solution like CodeSite or SmartInspect. They provide way more flexibility and features than any home-grown solution based around the event log and do not require you to step through the code, like the IDE does (which affects timings in multi-threadeded problems).

Update

Sorry, didn't get that FOSS stands for Free and Open Source Software. CodeSite and SmartInspect are neither. For a free solution, you could have a look though at the logging features within the Jedi family of tools.

Answer 6

Rad Studio XE includes a light version of CodeSite, and AQTime, which together are both compelling improvements.

You could do a lot with JCL Debug, MadExcept, and other profiling and logging tools, but CodeSite and AQTime are the two best for their respective tasks.