Приложение Delphi имеет "Нет информации об отладке" при отладке

Мы создали приложение, которое использует пакеты и компоненты. Когда мы отлаживаем приложение, "Журнал событий" в среде IDE часто показывает, что наши BPL загружаются без отладочной информации ( "No Debug Info" ). Это не имеет смысла, потому что все наши пакеты и EXE построены с отладкой.

_(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

У нас есть 4 проекта, построенных с помощью pacakges:

Core.bpl
Components.bpl
Plugin.bpl(использует как # 1, так и # 2)
MainApp.exe(использует # 1)

Наблюдаемые проблемы

1) Много раз, когда мы отлаживаем, Components.bpl загружается с информацией об отладке, но все значения в окне "Локальные переменные" пусты. Если вы наведите указатель мыши на переменную в коде, всплывающее окно не появится, и окно Evaluate также не покажет ничего (панель "Результат" всегда пустая).

2) Иногда в журнале событий отображается "No Debug Info" для разных BPL. Например, если мы активируем проект Plugin.bpl и установите его Run | Приложение Host Parameter для MainApp.exe, а затем нажмите F9, все модули, похоже, загружаются с помощью "Имеет информацию отладки", за исключением модуля Plugin.bpl. Когда он загружается, в журнале событий отображается "No Debug Info" . Однако, если мы закроем приложение и сразу же нажмем F9, он снова запустит его, не перекомпилируя что-нибудь, и на этот раз Plugin.bpl загрузится с отладкой ( "Has Debug Info" ).

Вопросы

1) Что приведет к тому, что окно "Локальные переменные" не отобразит значения?

2) Почему BPL иногда загружаются без отладочной информации, когда BPL выполняется с отладкой, и доступны все файлы отладки (dcu, map и т.д.)?

Ответ 1

Для нашей конкретной ситуации мы смогли исправить проблему, объединив Core.pbl и Components.bpl в одну BPL. Теперь все модули загружаются с информацией об отладке, и иногда возникает проблема, когда окно Locals не отображает значения для переменных.

Ответ 2

Я бы описал свою проблему с ней.

Я динамически загружаю пакет с помощью функции LoadPackage.

Я могу видеть в SysInternals.com Process Monitor, что packagename.DCP открылся и прочитал succesfuly после LoadPackage обработано - никаких попыток ввода-вывода файла не было, нет попытки найти его в неправильных местах, ничего подозрительного. Так что, возможно, в DCP есть какая-то конструкция, которая делает отладчик IDE гайкой. Я долго хотел, чтобы время Turbo Debugger было доступно для Delphi.

BTW, то же самое для packagename.RSM один создает такой.

Затем (в то время как пауза в точке останова или трассировке шага) я открываю Просмотр/Отладка Windows/Модули, а последний модуль - мой - и у него есть пустая ячейка "символьная информация". Я нажимаю его правой кнопкой мыши, выбираю "Повторно загружать символы" , и вот он, с этого момента я могу отлаживать.

PS. Dunno, если это поможет мне отлаживать разделы инициализации, хотя, надеюсь, элемент меню "break on load" будет работать даже с динамическими вызовами LoadPackage...

ПФС. Он действительно работает, даже через перезапуск IDE. Итак, теперь я предупрежден о загрузке BPL с помощью CPU View, я strike CTRL+ALT+M, прокрутите вниз, чтобы найти мою BPL, r-кликнуть на Reload Symbols, нажмите Enter, затем закройте Modules и CPU Виды и удары F9 (Run). После завершения разделов initialization я снова предупреждаюсь CPU View - всего несколько JMP перед выходом из LoadPackage - так что я закрываю CPU View и покачиваю F9 еще раз. Довольно утомительно, но все же лучше, чем перезагрузка IDE.

Ответ 3

Этот неофициальный инструмент устраняет многие проблемы с Delphi. Он зафиксировал загрузку модуля без отладочной информации для меня. Все кредиты magicandre1981.

Ответ 4

Мы столкнулись с аналогичной проблемой в нашем проекте. К сожалению, у нас есть десятки bpl, поэтому мы не можем объединить их в одном. Эта проблема появилась после того, как мы перешли на XE2 и изменили структуру папок нашей цели компиляции. Хотя трудно сказать, что если новые версии Delphi представили проблему или нет, мы могли бы исправить проблему, добавив папку, в которой bpls скомпилированы в переменной окружения. Использование функции переопределения пути в среде IDE. Этот тип конфигурации не был необходим в Delphi 2010...

Ответ 5

Вы должны создать свои отдельные пакеты с информацией об отладке, и в конечном итоге вы захотите создать их без отладки - так что у вас будет как в двух местах. Затем вы хотите создать свой проект приложения с информацией об отладке. Проверьте свои пути, чтобы убедиться, что вы включили источник пакета с поддержкой отладки в своих сборках проектов отладки. Похоже, вы можете включать в себя пакеты, которые были созданы без отладки, потому что вы включаете неправильный источник. Вы должны убедиться, что у вас нет обоих путей, включая Delphi, чтобы выбрать, что включать, если он найдет тот же пакет в двух местах.

Ответ 6

Эта проблема может быть отправлена в QС# 109291:

Когда Delphi IDE начнет вводить файл .dproj и строить конфигурацию с помощью наборов опций, это значительно облегчит управление выпуском проекта.

Однако он также имеет побочный эффект, который трудно воспроизвести и поймать, и я подумал, что это ошибка в среде IDE. Проблема должна всегда путать пользователей, где какой-то проект не может отлаживать отладчик IDE. Даже мы проверяем все связанные настройки параметров компилятора и ссылок в проекте, отладчик не активируется в проекте. Некоторые проектные работы и некоторые проекты этого не делают. Мы даже считаем, что это проблема памяти или проблема с CPU.

Я заметил, что проблема связана с тем, что параметр .dproj не сохраняет правильную информацию. Если связанный файл .dproj имеет что-то вроде этого:

<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>

Release.optset привязка к Cfg_2 и Debug.optset привязка к Cfg_1, но Release конфигурация использует Cfg_1 и Debug в конфигурации используется Cfg_2.

При создании проекта информация об отладке не будет генерироваться в конфигурации отладки, а будет генерироваться при конфигурации выпуска.

Обходное решение открыто .dproj с любым текстовым редактором, но не с Delphi IDE, и обновляется до:

<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>

Ответ 7

Я нашел в файле .dprj одну строку в Cfg_2 détails со значением Debugger_LoadAllSymbols, для которого установлено значение false. Я сделал это правдой. Задача решена. Может быть, не похоже на ваше дело, но может помочь.

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