Some tips for debugger

by Radek Červinka 20. September 2010 22:26

With debugging we usually spends much of the time for program development. I will not underestimate you and show the basic things like entering a breakpoint, but try something other.

I'm not sure which version of Delphi supports the feature, but some of these are long and some Delphi until 2010 or XE.

Breakpoints group

Next program is created for demonstration purposes, in real life we use breakpoint grouping in complex cases.

Breakpoint group

We want the program to stop at line 17 in the case when i = 10 and j = 100. One option is to put a breakpoint at line 17 and set condition for i = 10 and j = 100, which is of course possible. One drawback is the slow run - evaluation of conditions for many calls is remarkable. Another disadvantage in some cases impossible to determine the exact conditions (asynchronous events).

Breakpoint properties - as well for sure: we set a breakpoint by clicking on the blue dot - that symbolizes the line, which was included in the resulting binary file. If the dot is not displayed, the line was eliminated by linker - code has no signification or not called (for procedures). Breakpoint properties are displayed when click on the breakpoint (red dot) with right-click.

So breakpoint properties allow us to define the rules for which the breakpoint stops the program. In our case we set breakpoint for line 14 as on picture (set condition and subject to enable a group of breakpoints cyklusJ).

breakpoint properties

Now for line 17 we define breakpoint belonging to the group and set his condition. The last thing we still have to do is disable a breakpoint (in popupmenu on the breakpoint - enabled - otherwise the whole of our actions did not have much meaning). Inactive breakpoint is gray.

breakpoint properties

Now run the program and when the program stops at the first breakpoint, second breakpoint is activated and (after 100 cycles) also stops the program.

And about Pass count. You can define how many times the program has to pass a breakpoint before the program stops.

Write to log with breakpoints

Write to log can sometimes be useful. When program pass breakpoint, debugger can write to Event logu.

breakpoint properties

I wrote a very complicated and roughly optimized expression for Eval Expression (i*j) that Delphi will write if it passes this breakpoint (I deleted groups)and also check checkbox "Log call stack" for dump of call stack.

The disadvantage is that the program always stops. In task like mouse capture or drawing is not so good. But just uncheck Break and program will run without break and the Event Log display information.

výpis z Event logu

Named thread

If you are writing multithreaded applications certainly find a problem what is this thread. Delphi since 2010 (with improvements in XE) have a nice trick.

Almost everybody knows that the threads are in Delphi successor of class TThread with override method Execute. Now that class has

    1class procedure TThread.NameThreadForDebugging(AThreadName: AnsiString;
    2       AThreadID: TThreadID = TThreadID(-1)); static;

Calling this class procedure in your program allowing debugger display better name for thread instead of ThreadID.

Classic Sort demo from Delphi installation:

    1procedure TSortThread.Execute;
    2begin
    3  NameThreadForDebugging(AnsiString(ClassName));
    4  Sort(Slice(FSortArray^, FSize)); // vlastní implementace řazení
    5end;

named threads

ThreadID = 9156 is main application thread. With his popup menu you can rename this thread too:

named threads

Very good extension.

Tags: ,

Practices

Comments

9/23/2010 11:09:02 PM #

Radim

Vdaka.

Radim |

Comments are closed