В приложении Delphi «Отладочная информация отсутствует» при отладке - PullRequest
13 голосов
/ 09 января 2012

Мы создали приложение, которое использует пакеты и компоненты. Когда мы отлаживаем приложение, «Журнал событий» в 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 проекта, все построены с пакетом времени выполнения:

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

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

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

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

Вопросы

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

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

Ответы [ 7 ]

4 голосов
/ 03 октября 2012

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

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

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

Кстати, то же самое для packagename.RSM - это один из них.

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

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

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

4 голосов
/ 04 июня 2014

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

4 голосов
/ 13 августа 2012

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

2 голосов
/ 05 октября 2012

Эта проблема может быть устранена до QC # 109291 :

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

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

Я заметил, что проблема в том, что файл .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>
2 голосов
/ 11 января 2012

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

2 голосов
/ 09 января 2012

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

0 голосов
/ 13 августа 2013

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

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