Delphi App has "No Debug Info" when Debugging

Question

We have built an application that uses packages and components. When we debug the application, the "Event Log" in the IDE often shows the our BPLs are being loaded without debug information ("No Debug Info"). This doesn't make sense because all our packages and EXEs are built with debug.

_(each project) | Options | Compiling_
[ x ] Assertions
[ x ] Debug information
[ x ] Local symbols
Symbol reference info = "Reference info"
[   ] Use debug .dcus
[ x ] Use imported data references

_(each project) | Options | Linking_
[ x ] Debug information
Map file = Detailed

We have 4 projects, all built with runtime pacakges:

1. Core.bpl
2. Components.bpl
3. Plugin.bpl (uses both #1 & #2)
4. MainApp.exe (uses #1)

Problems Observed

1) Many times when we debug, the Components.bpl is loaded with debug info, but all values in the "Local Variables" window are blank. If you hover your mouse over a variable in the code, there is no popup, and Evaluate window also shows nothing (the "Result" pane is always blank).

2) Sometimes the Event Log shows "No Debug Info" for various BPLs. For instance, if we activate the Plugin.bpl project and set it's Run | Parameter's Host Application to be the MainApp.exe, and then press F9, all modules seems to load with "Has Debug Info" except for the Plugin.bpl module. When it loads, the Event Log shows "No Debug Info". However, if we close the app and immediately press F9, it will run it again without recompiling anything and this time Plugin.bpl is loaded with debug ("Has Debug Info").

Questions

1) What would cause the "Local Variables" window to not display the values?

2) Why are BPLs sometimes loaded without debug info when the BPL was complied with debug and all the debug files (dcu, map, etc.) are available?

Palmirapalmistry

Answer 1

For our particular situation we were able to fix the issue by combining the Core.pbl and Components.bpl into a single BPL. Now all modules are loaded with debug info and the occasional issue where the Locals Window wouldn't display values for the variables is resolved.

Palmirapalmistry

Combine the BPLs to get rid of the problem is not a good solution. Imagine if you have hundred of dynamic packages, it is impossible to combine into a single BPL. – Maturation

@ChauCheeYang - We do have dozens of other BPLs. It was just the separation of these two that caused the problem. In our case, combining those two was acceptable -- while leaving the other dozens separate... It might of had something to do with the Components.bpl depended heavily upon Core.bpl. – Palmirapalmistry

Did you use optset reference for both debug and release configuration? – Maturation

I have posted a new answer that may help to solve the problem. – Maturation

Answer 2

I would describe my issue with it.

I dynamically load package using LoadPackage function.

I can see in SysInternals.com Process Monitor that packagename.DCP got open and read succesfuly after LoadPackage processed - no file I/O failed, no attempt to find it in wrong places, nothing suspicious. So perhaps there is some construct in DCP that makes IDE debugger go nuts. I long for times when Turbo Debugger was available for Delphi.

BTW, same is for packagename.RSM if developer creates such.

Then (while paused at breakpoint or Step Trace) i open View / Debug Windows / Modules and see last module is mine - and it has empty "symbol information" cell. I right-click it, choose "Re-load symbols" action - and here it is, from now on i can debug.

PS. Dunno if that would help me to debug initialization sections though - hopefully "break on load" menu item would work even with dynamical LoadPackage calls...

PPS. It does work indeed, even across IDE restarts. So now i am alerted at BPL loading with CPU View, i strike CTRL+ALT+M, scroll to bottom to find my BPL, r-click to Reload Symbols, press Enter, then close Modules and CPU Views and strike F9 (Run). After initialization sections completes i am again alerted by CPU View - just few JMPs before exit out of LoadPackage - so i close CPU View and stike F9 yet again. Quite tedious, yet still better than IDE restart.

Kucera

Doesn't answer why the debug info is missing, but +1 for the helpful workaround. That's much better than restarting Delphi and trying again and again until it finally works. – Palmirapalmistry

it is not missing, it is present in BPL - CFF Explorer shows this. the fact is that IDE does not use it - it uses DCP file instead. And if there are several DCP files - then it fails. However why it sometimes fail even when the only DCP present and it clearly read that file ok - that is mystery. In my case i found same-named units EXE : Path1\name and BPL1 : Path2\name - however BPL1 and BPL2 loadedokay and only dynamically-loaded BPL3 was affected. Anyway, SysInit unit would be cloned in all EXE/DLL/BPL files so that should not confuse IDE debugfer. Mistery. PS thx 2u for noting Modules view – Vyky

You're welcome -- but I never tried right-clicking to tell it to 'reload symbols'. That's a nice new trick. – Palmirapalmistry

Long time no see, James. I just found that while i had XE2 Upd4 HF1 installed, in Windows\System32 i had rtl160bpl and vcl160.bpl of some previous 2011 version (update1 ? dunno). So porgram compiled against RTL/VCL in c:\RAAD Studio\9.0\... and was run and debugged against another BPL versions. That also a lot of troubles when debugigng inside RTL, evaluatning variable.classname and such. I deleted those legacy global BPLs and for few hours this issue did not repeated. Hopefully it would not re-occur or would do much more rare – Vyky

This answer was visited in 2020, wow. The two BPLs aforementioned were of XE2 Upd3 version and were installed by (AFAIR) Raize CodeSite remote logging plugin. Overall, the 4th update seems to be of half-baked quality and broken important thins, like COM interop with Microsoft Office – Vyky

Answer 3

We have encountered a similar issue in our project. Unfortunately we have dozens of bpl so we cannot merge them in one. This issue appeared after we migrated to XE2 and changed the folder structure of our compile target. While it is difficult to say if newer versions of Delphi introduced the issue or not, we could fix the issue by adding the folder where the bpls are compiled in the path environment variable. Using the path override function of the IDE. This type of configuration was not necessary in Delphi 2010...

Itis

Answer 4

This non-official tool fixes many issues with Delphi. It fixed the module loading without debug info for me. All the credits to magicandre1981.

Businessman

I was having a trouble with debugging design packages in Delphi XE6, IDE didn't want to load debug info. This tool helped, thanks! – Buckjump

I was also landing on the 'CPU' tab each time a breakpoint was hit -> my bpl and app were loaded without Debug Info. I installed this tool and it just worked. Thx! – Paynter

this did not fix for me in XE2 though. Crazy thing, Andy as far as i could got it has Delphi sources (not RTL/VCL. but IDE itself) so can fix bugs on source levels. Why those bugs often persists acrosss Delphi releases then is completely enraging. – Vyky

Answer 5

You have to build your separate packages with debug info, and you will eventually want to build them without debug also - so you will have both in 2 spots. Then you want to build your app project with debug info. Check your paths to ensure that you are including the debug-enabled package source in your debug project builds. It sounds like you may be including packages that were built without debug because you are including from the wrong source. You have to make sure you don't have both paths included, leaving Delphi to select what to include if it finds the same package in two places.

Encephalomyelitis

All of our projects are built with debug, and both DEBUG and RELEASE use the same output folders. So it isn't a problem with the packages being built without DEBUG or that the debugger is finding the RELEASE versions of any of the packages... We will check the paths though to be sure that the debug DCUs are being properly found. Thanks for the suggestions. – Palmirapalmistry

+1 for your suggestion to check the paths. This led me to open the Debug Modules window, which shows where the debug symbols are being loaded. This helped lead me to the idea that solved the issue (see answer below). – Palmirapalmistry

Answer 6

This problem might be releated to QC#109291:

When Delphi IDE start introduce .dproj file and build configuration with option sets, it improve the project release management a lot.

However, it also has a side effect that is hard to replay and catch and I thought it was bugs in IDE. The problem should have always confuse the users where some project is not able to debug in IDE debugger. Even we check all the related settings the compiler and linking options in project, the debugger won't activate on the project. Some project works and some project doesn't. We even regard is to be memory problem or cpu problem.

I notice the problem is due to the .dproj file setting doesn't store correct information. If the related .dproj file has something like this:

<PropertyGroup Condition="'$(Config)'=='Release' or '$(Cfg_1)'!=''">
    <Cfg_1>true</Cfg_1>
    <CfgParent>Base</CfgParent>
    <Base>true</Base>
</PropertyGroup>
<PropertyGroup Condition="'$(Config)'=='Debug' or '$(Cfg_2)'!=''">
    <Cfg_2>true</Cfg_2>
    <CfgParent>Base</CfgParent>
    <Base>true</Base>
</PropertyGroup>

<Import Project="Release.optset" Condition="'$(Cfg_2)'!='' And Exists('Release.optset')"/>
<PropertyGroup Condition="'$(Cfg_1)'!=''">
    <CfgDependentOn>Release.optset</CfgDependentOn>
</PropertyGroup>
<Import Project="Debug.optset" Condition="'$(Cfg_1)'!='' And Exists('Debug.optset')"/>
<PropertyGroup Condition="'$(Cfg_2)'!=''">
    <CfgDependentOn>Debug.optset</CfgDependentOn>
</PropertyGroup>

The Release.optset bind to Cfg_2 and Debug.optset bind to Cfg_1 but Release configuration is using Cfg_1 and Debug configuration is using Cfg_2.

When build the project, the debug info will not generate for in debug configuration but generate on release configuration.

A workaround solution is open .dproj with any text editor but not Delphi IDE, and update to:

<Import Project="Release.optset" Condition="'$(Cfg_1)'!='' And Exists('Release.optset')"/>
<PropertyGroup Condition="'$(Cfg_1)'!=''">
    <CfgDependentOn>Release.optset</CfgDependentOn>
</PropertyGroup>
<Import Project="Debug.optset" Condition="'$(Cfg_2)'!='' And Exists('Debug.optset')"/>
<PropertyGroup Condition="'$(Cfg_2)'!=''">
    <CfgDependentOn>Debug.optset</CfgDependentOn>
</PropertyGroup>

Maturation

This looks promising, but I won't be able to test it until I run into a situation again where the debug information is missing. Thank you for sharing your experience. – Palmirapalmistry

True. I solved many problems by deleting the dproj file and letting Delphi regenerate it. One of the many many examples: #21959075 – Laceylach

Answer 7

I found in the .dprj file one line in the Cfg_2 détails with value Debugger_LoadAllSymbols which was set to false. I did set it to true. Problem solved. Maybe not similar to your case, but may help.

<PropertyGroup Condition="'$(Cfg_2_Win32)'!=''">
...
    <Debugger_LoadAllSymbols>true</Debugger_LoadAllSymbols>
...
</PropertyGroup>

Audiometer