Delphi Debbuger Blue Dot But Red With Cross

admin

Nov 10, 2008 Delphi includes a line in source code into the compiled result, it puts a blue dot beside it. My dots don't line up in one of my units so that I can't debug the unit. This seems to occur half way down the unit, and I see no special reason why it should be. I've tried deleting lines to. Remarks: all options for debugging are set properly (as for F7 causes delphi stop at the 'begin' of the program, blue dots are visible in the whole unit the line stays red while executing the app) and all DCUs that have according PAS files were deleted from all of my disks and within all folders, before I did a complete build on the whole project. Apr 08, 2008 and dpr files. Everything else we let Delphi create. I don't have a tds, blowing the dcu's aways doesn't help. I don't see a debug path anywhere, but it is in lib path. Other units in the same folder work just fine. It feels like a limitation in Delphi somewhere. Jul 13, 2017 Breakpoints are used to debug code lines. Generally we put a breakpoint on a source code line to trace at debug time. We can put break point by pressing the F5 button or clicking on the left bar in your code editor, it will put a red point to your source code line. When running the program, the execution will stop when it passes the source line.

When I work on my IDE plugins I constantly need to debug the IDE. To make my live a lot easier I wrote an IDE plugin that adds another symbol resolver to the Delphi Debugger, so the debugger can use the *.jdbg files and show the actual function names (including line numbers) in the call stack. Even the CPU view uses more colors to show call, jmp, ret, nop, try/finally/except and more in different colors and resolves call and jump target addresses to their names if available.

In order to identify the code that causes performance issues I use “poor man’s profiling”. I pause the IDE multiple times while the task that takes up the time is running and look at the call stack. If a function comes up in all call stacks, it is is either the culprit or a function that is called very often (or you are just unlucky).

If the task takes really long, pausing the IDE withing the debugger IDE via the pause button is doable, but if the task takes only 2 seconds switching to the other IDE or moving the mouse to the pause button can be too slow, so I use the F12 debug hotkey that Windows reacts to and notifies the debugger to pause the process. Unfortunately Microsoft disabled that feature with Windows Vista. So I had to emulate that functionally with my own IDE plugin that reacts to the F12 hotkey while the debugger is running.

Tools used:

Installing the IDE plugins

Both tools come without an installer, so you have to install them by hand. Creatures of influence information society. After extracting the 7z files you have to create two registry entries (Delphi 10.3 Rio):

  1. Start regedit.exe
  2. Navigate to HKEY_CURRENT_USERSoftwareEmbarcaderoBDS20.0Experts
  3. If the “Experts” key doesn’t exist, you have to create it by right clicking on the “20.0” key and select “New/Key”
  4. Add a new String value by right clicking in the listview and select “New/String Value”.
    Name: DebuggerCallStackResolverR103
    Value: C:ThePathToDebuggerCallStackResolverR103.dll
  5. Add another String value by right clicking in the listview and select “New/String Value”.
    Name: DelphiF12HotKeySupport
    Value: C:ThePathToDelphiF12HotKeySupport.dll
  6. Close regedit.exe

Starting the debugger IDE

Start the RAD Studio IDE. There is nothing special here.

Starting the IDE that we want to debug

For IDE plugins and component packages

If you are writing an IDE plugin or want to debug a component, you open your project and in the “Run/Parameters…” dialog set the “Host application” to “$(BDS)binbds.exe” (without the quotes). If you want to use a different registry key for the debugged IDE then you can also set the “Parameters” to “-rMyRegistryKey“. That way the IDE starts with a new registry key having a clean IDE, so it doesn’t have any additional library paths, components or IDE plugins installed that.

Compile and Start your project.

I use the -r command line parameter for my IDE plugins because the debugged IDE has to load the just compiled versions of the DLLs instead of the release versions that are installed into the debugger IDE.

Delphi Debbuger Blue Dot But Red With Crossing

Just for call stacks

If you only want to identify an IDE bug or a performance issue you can start the second IDE without opening any project by using the “Run/Load process…” dialog. Select the “Embarcadero Windows 32bit-Debugger” in the Debugger combo box and set the “Host application” to “$(BDS)binbds.exe” (without the quotes). Set the “After load” radio button to “Run” and press the “Load” button.

Skipping the usual startup exception

The IDE throws some exception during the startup, that are handled by the IDE but now that a debugger is attached to the IDE’s process you will see them.

The first exception you may encounter is an EFOpenFile exception for the “%USERPROFILE%sanct.log” file. That has something to do with the product licensing and now that two IDEs are running the first holds the file exclusively open causing the second IDE to fail to open the file. You can ignore this exception (you may add the EFOpenFile exception to the ignore list if you start the debugged IDE multiple times.

The next exception is ESanctSocketException “Cannot start instance counter. Port is already in use (10048).”. Again caused by the product licensing. This time it wants to listen to a port but the debugger IDE already opened that port. Add that exception type to the ignore list because we don’t care about it and the exception type is a special type not like EFOpenFile)

The EFOpenFile exception for the sanct.log file is thrown again. Skip it again.

Delphi Debbuger Blue Dot But Red With Cross

And finally we reach the EAccessViolation from the welcome page (something the IDEFixPack for Rio will fix). Skip that one.

If you are in the editor you may see an EParseError exception. You can add that exception to the ignore list.

Identifying the performance issue

Now you can start the task that you think is taking a lot of time and while it is causing the CPU or I/O usage to be high, you can pause the debugged IDE by pressing the pause button in the first IDE or by pressing the F12 debug break hotkey in the debugged IDE. This brings you usually to the CPU view and you can have a look at the call stack of all the threads by double clicking on a specific thread in the Threads list what shows the thread’s call stack in the Call Stack window.

Delphi - Component Debug

OK . you have designed a component and it doesn't work.

Now what?

This page contains a few of the more difficult design problems that I have had to work through. I hope it helps.

Constructor Missing 'inherited' | Wrong *Package* Name

Constructor Missing 'inherited'

If you forget the requiredinherited in the constructor, then the component will be created and work just fine . unless . you place it on the form at design time. In that case, the variable that makes the component available will not be set. 
     T_xyz = class(TComponent) public constructor Create(AOwner: TComponent); override; end; constructor T_xyz.Create(AOwner: TComponent); begin inherited; // the problem was caused by forgetting this // additional code here end;
Using the following code, I was able to verify that when the program started, an object of type T_xyz was created (verified by setting a breakpoint in the

Delphi Debugger Blue Dot But Red With Cross Design

constructor), yet the variable

Delphi Debugger Blue Dot But Red With Cross Stitch

xyz1 was not assigned a value (was equal to nil - verified by setting a breakpoint) when FormCreate was called. Adding inherited to the constructor fixed the problem. 
     type TForm1 = class(TForm) xyz1: T_xyz; abc1: T_abc; private { Private declarations } public { Public declarations } end; implementation procedure TForm1.FormCreate(Sender: TObject); begin abc1.xyz := xyz1; // xyz1 = nil when inherited was forgotten end;
I found this by accident . after single stepping through source code for about 5 hours. I simply noticed that the command was missing.

Wrong *Package* Name

When creating a new group of related components, I don't want to place the new stuff in with items I have already tested and released. Instead, I create a new package and use that to test while developing. When the testing is done, sometimes I merge the components into an existing package and sometimes not.

Megaman x5 pc download exe. The basic (and wrong) procedure is

  • Create a new package
  • Compile
  • Install

This produces a default package name of

    C:Program FilesBorlandDelphi5ProjectsPackage1.dcu
    C:Program FilesBorlandDelphi5ProjectsBplPackage1.dcp
    C:Program FilesBorlandDelphi5ProjectsBplPackage1.bpl

At this point you can select your new components from the tool bar and place them on a form. If you want to change the code,

  • Just recompile the package
  • The form will be automatically closed
  • Reopen the form (press F12) and the new properties (and whatever) will be displayed

OK, so now you save the package and give it a proper name. (Wow, are you screwed!!)

That's right, the old package is still there! You can write, compile, change whatever you want, and nothing is going to get fixed.

After 2 days of debugging a (very serious) problem, I decided to try and click Install again. That's when I saw the error

    Cannot load package 'dcl_mcXYZ_50.' It contains unit 'mcABC,';which is also contained in package 'Package1'
(Boy, was I surprised)

Of course, the solution was simple

  • Unload the bad package
  • Load the correctly named package
There was another clue, (I know, sometimes I'm slow)
    Previously, each time I compiled the package, the form would close . because it contained components from that package. However, on the next day, clicking compile did not force the form to close.
I had just assumed that 'Delphi was mysterious' and ignored this clue. (You have to make some mistakes before the symptoms make sense.)

Correct Procedure

As explained in more detail at Creating a Package, the 'more correct' procedure is
  • Create a new package
  • Add the *.pas files
  • Save the package (*.dpk file)
  • Compile
  • Install
My problem was that I installed the package before saving (and therefore - naming) it. As a result, the package was originally installed using a default name and all source code changes made after the save were ignored.

More

By the way, the error I was getting (a Google search found nothing)
    (Access violation at address 40003CAE in module 'Vcl50.bpl'. Read of address 000000EC)
was caused while testing the proper operation of my component at design time. (It worked perfectly at runtime.) Basically, the new component has a published property that holds a pointer to another component. At design time, the property was set using the Object Inspector . and everything worked fine. The problem occurred when I deleted the second component. Normally, this causes the property value to be cleared (which verifies that the notify flags are properly set) . when there is a problem . Delphi crashes. (This is a standard test that mustDot be tried for every property that can hold a pointer to an object on the form.)

However, since this is a design time failure, there are no useful debug tools (that I know of) that simplify problem identification. As a result, I slugged through the source code trying to see what was wrong. In desperation, I tried to reinstall the package . and found the problem.

Deleting the old Package

To delete the a package, there are 2 methods.
  • From the menu, select
      Component / Install Packages..
  • Open the new (properly named) package in Delphi. From the toolbar, select the Options icon and click on the Packages tab

Delphi Debugger Blue Dot But Red With Cross Pattern

From this point, both methods are the same - simply select the bad package and click Remove.

Delphi Debugger Blue Dot But Red With Cross Reference

In this case, I selected

    C:Program FilesBorlandDelphi5ProjectsBplPackage1.bpl
None of the files were deleted, but the package was uninstalled and the icons on the toolbar were removed.

When I installed the new (properly named) package, the icons were restored and the design time error was fixed. In the final analysis,

  • The error was because I forget to include inherited in the constructor
  • And could not be fixed because I installed the package before I saved it with a proper name
Author: Robert Clemenzi

Delphi Debugger Blue Dot But Red With Cross Stitch

URL: http:// mc-computing.com / Languages / Delphi / ComponentDebug.html