Delphi 12 - Breakpoint not work when use Rumtime Packages and Win64 platform

[giorgiobazzo 1]

We are having problems with Delphi 12 to debug projects with Runtime Packages and the Win64 platform.

 

This example reproduces an issue when debugging projects that use Rumtime Packages on the Win64 platform.

Steps to reproduce the issue:

 

1 - Open the project group: BPTEST.groupproj;
2 - Select the debug configuration and the win64 platform for all projects in the group;
3 - Make a Build;
4 - In the App.exe project in App.dpr, place a breakpoint on the line: Application.Initialize;
5 - Press F9, and we will see that the breakpoint was ignored.

If we repeat the process with the win32 configuration, the breakpoint works correctly;

If in App.dpr we remove the MyUnit unit from uses, which is part of TrPartUnits.bpl, the breakpoint also works correctly even in win64;

 

I also made the example available at:

 

https://github.com/giorgiobazzo/RtPkgSample

BPTEST.zip

[Lajos Juhász 325]

Most probably it is a known issue. Here you can read more: 

 

 

[giorgiobazzo 1]

Hi @Lajos Juhász,

I had already looked at this post, but I thought the problem could be something else, as I am not using dynamically loaded packages. In my case, the packages are referenced in the projects' requires.
And another detail is that I don't have a problem with win32, only with win64.

[Lajos Juhász 325]

Unfortunately only @Marco Cantu could answer if this is the same bug. 

[Pat Foley 54]

program App;

uses
  Vcl.Forms,
  MyUnit, //From TrPartUnits.bpl, if remove, breakpoint works in win32 and win64 = please don't put MyUnit here
  AppForm in 'AppForm.pas' {Form2};

{$R *.res}

begin
  Application.Initialize; //Breakpoint here: on win32 is ok, but 64 the breakpoint dont stop!
  Application.MainFormOnTaskbar := True;
  Application.CreateForm(TForm2, Form2);
  Application.Run;
end.

If myunit is available in a library, it can't also be in the program's dpr.  Access the Library myunit in each unit uses clause as needed! 

 

If the unit uses clause doesn't see myunit adjust the path.  Putting my myunit in apps dpr will hide these issues and defeats the goodness of modular construction methods.    

[giorgiobazzo 1]

Hi @Pat Foley,

 

This example is very brief, just to demonstrate the debug problem in win64, because in win32, in the same way as in the example, the breakpoint works correctly.

 

In production I have groups of projects with several .bpl packages, and several executables that depend on the same packages, and also packages that depend on other packages. So a unit like myunit.pas can only be added to a single package. In this case, adding myunit.pas to all .dpk is not possible, this generates compilation errors, because the unit has already been added to another package.
Adding myunit.pas to App.exe's .dpr makes the breakpoint work on win64, but this is the same as not using Runtime Packages, so this is not a solution in this case.

[Pat Foley 54]

Quote

ip 8: Seldom Use Form1 In Other Forms Even in the code of other forms, try to avoid direct references to global objects, such as Form1. It is much better to declare local variables or private fields to refer to other forms. For example, the main form of a program can have a private field referring to a dialog box. Obviously this rule becomes essential if you plan creating multiple instances of the secondary form. You can keep a list in a dynamic array of the main form, or simply use the Forms array of the global Screen object to refer to any form currently existing in the application. From Macro Cantu's Sidney 10.4 Handbook

Reading between the lines means using a string for finding a form in runtime with the Screen.   Or Each Library should just launch its own forms or class var singleton form as needed.  

[giorgiobazzo 1]

@Pat Foley,

 

What does this have to do with the fact that breakpoint doesn't work in win64?

[Pat Foley 54]

uses
  Vcl.Forms,
           
  MyUnit, //From TrPartUnits.bpl, if remove, breakpoint works in win32 and win64

  AppForm in 'AppForm.pas' {Form2};

{$R *.re

Based on your info when the myunit is removed it compiles.

 

Delphi 12 in debugger mode even with update often shows the dissembler first under a tab. To avoid compile the program and start the program using the browser in "attach to process" under the run button to start the executable and press f7-f9 buttons if hung up in the dissembler.  If blue dots not lined up with the source check path.  

[giorgiobazzo 1]

@Pat Foley,

 

The problem is not compiling, the code always compiles, with or without MyUnit.

The problem is only with the breakpoints.

I opened a ticket at: https://idera.my.salesforce-sites.com/CG/

 

And here it was reported that the debug for win64 actually has this problem, and that it should be corrected in future updates. So it's not something we're doing wrong, but rather a problem that Delphi currently has.

 

[giorgiobazzo 1]

David Millington pointed me to a solution, through the support of Embarcadero:

 

Quote

 

Hi. Our engineer has analysed and discovered that this happens because the App.exe uses MyUnit from TrPartUtils.bpl. When the debugger tries to resolve the debug symbols for App.exe, it sees that EXE uses MyUnit, and it cannot find the debug symbols for MyUnit. The MyUnit debug symbols are located in TrPartUtuils.dcp, and that’s not being found.

In order to fix the issue, the IDE needs to be able to find the debug symbol for MyUnit (ie, find TrPartUtils.dcp) by doing the following:
a. open TrPartUtils.project.
b. open Options | Building | Delphi Compiler | DCP output directory, copy this value.

c. open App project
d. open project | options | debugger | symbol tables, and enter ..\Build\$(Platform)\$(Config)\Dcp
This value is the value that is found in item b) above.

The IDE should then be able to find the debug info for MyUnit, as well as all other units in TrPartUtils. This should also then re-enable the breakpoint in the DPR. I (David) am still discussing internally why the breakpoint in the DPR file is not working there when the used unit’s debug info is now found, but either way, finding the DCP should resolve the issue.

 

 

This solved the problem for me.

 

 

 

[kukoj 0]

On 5/27/2024 at 8:43 AM, giorgiobazzo said:

David Millington pointed me to a solution, through the support of Embarcadero:

It works for me too!