64-битная отладка Delphi с использованием библиотек времени выполнения имеет неправильный активный кадр стека

Я столкнулся с проблемой отладки Win64, когда похоже, что мы «отсутствуем» отладочной информации. Поэтому я провел небольшое исследование и воссоздал все свои файлы . dproj для нашего флагманского продукта. Это помогло, так как я вернул свои «пропавшие» синие шары.

Но теперь я столкнулся с новой проблемой: (верхний) кадр стека, отображаемый в окне отображения стека, кажется неправильным, что приводит к тому, что локальные переменные не отображаются на панели локальных переменных, а также не отображаются при наведении курсора мыши на какую-либо переменную. . Но когда я выбираю кадр стека, который считаю правильным, окно локальных переменных больше не пусто. Наведение мышки по-прежнему ничего не показывает.

Также проверьте связанные скриншоты, которые должны многое прояснить.

Соответствующие параметры компилятора

  • Информация об отладке: Информация об отладке
  • Местные символы: правда
  • Кадры стека: правда
  • Справочная информация о символе: справочная информация
  • Использовать отладку dcus: False
  • Использовать ссылки на импортированные данные: True
  • Информация об отладке компоновщика: True
  • Включить символы удаленной отладки: False

Информация о версии:

  • RAD studio Enterprise 10.2.3 Токио, сборка 25.0.29899.2631
  • Установлен DDevExtension, установлен IDFixPack (удаление не имеет значения)
  • JCLDebug установлен (удаление не имеет значения)

Я поиграл со многими комбинациями параметров отладки, но проблема не устранена в моей системе.

Компьютер моего коллеги имеет точно такую ​​​​же проблему в том же коде, поэтому, по крайней мере, он воспроизводим с уверенностью. При попытке воспроизвести это с помощью небольшого проекта с bpl во время выполнения проблема не возникает, или я не могу ее воспроизвести. Следовательно, у меня нет источника для выпуска для этого.

И, конечно, вот вопросы: - Кто-нибудь еще сталкивался с этим? - нашел решение? - Поделись, пожалуйста! - Не нашли решение? -> добавьте комментарий/голосуйте за эту проблему

Я хотел бы добавить несколько фотографий для пояснения, но, к сожалению, моя репутация еще недостаточно высока. Так что я могу только добавить ссылки на картинки, извините за это.

  • Точка останова в представлении исходного кода
  • Точка останова при полном представлении ЦП
  • Выберите нижний кадр стека
  • Ещё на один уровень глубже, неожиданная вершина стека
  • Предыдущая инструкция привела к искажению отображения стека

debugging delphi watch stack-frame win64
person H.Hasenack    schedule 12.06.2018    source источник
comment
Очевидный и, вероятно, наиболее подходящий вариант — кадры стека в Delphi Compiler -> вкладка Compiling. Ты это включил? Если вы можете обычным способом поставить какую-нибудь точку останова ниже в стеке вызовов, а затем проследить код до тех пор, пока стек вызовов не начнет отображаться неправильно. Затем вы можете проверить, не повлияло ли что-то на это и может запутать обход стека отладчика.   -  person Stefan Glienke    schedule 12.06.2018
comment
Пробовал, к сожалению, без удовольствия.   -  person H.Hasenack    schedule 12.06.2018
comment
Трассировка стека в порядке непосредственно перед тем, как я ввожу вызов TfrmNewAnalyses.Create. После входа в конструктор кадр стека разрывается.   -  person H.Hasenack    schedule 12.06.2018
comment
Я добавил еще один скриншот. После выполнения инструкции перемещения 0315D746 отображение стека искажается.   -  person H.Hasenack    schedule 12.06.2018
comment
Типичный сбой отладчика, вызванный некоторым кодом, сгенерированным компилятором в прологе, который он неправильно интерпретирует. Вы можете попробовать закомментировать операторы в методе, чтобы увидеть, что вызывает это, и, возможно, написать их по-другому, как только вы обнаружите это. Но я думаю, что теперь это выходит за рамки возможностей SO.   -  person Stefan Glienke    schedule 12.06.2018
comment
а, хороший совет, Стефан. Я добавил вызов MessageBox прямо перед унаследованным вызовом, но никакой разницы. Далее закомментирован весь код, кроме унаследованного вызова. Все равно никакой разницы. Я согласен, что это выходит за рамки SO. Поэтому, пожалуйста, проголосуйте за мою проблему и поднимите мою репутацию, чтобы моя жизнь стала проще здесь, в StackOverflow: p   -  person H.Hasenack    schedule 12.06.2018
comment
Спасибо за голосование!   -  person H.Hasenack    schedule 12.06.2018

Ответы (1)


arrow_upward
0
arrow_downward

Как оказалось, здесь происходит что-то совсем другое. Отсутствующие локальные символы, по-видимому, вызваны тем, что отладчик не загружает ВСЮ отладочную информацию. Я создал модульный тест для загрузки BPL среды выполнения. Когда я запускаю свою форму (проверьте скриншоты) из модульного теста, стековые фреймы и локальные символы отображаются правильно. Когда я запускаю форму из своего довольно большого приложения, то точно такой же двоичный файл bpl НЕ показывает локальные символы и стек Информация. Как ни странно, другие модули в том же BPL на самом деле показывают правильную информацию о стеке и локальных переменных, например, модуль, который создает форму, в первую очередь в порядке до того места, где создается конструктор формы.

Итак, я догадался, что что-то происходит с загрузкой таблицы символов. И когда я меняю настройки отладки на то, что показано на скриншоте (Load All SYmbols=off, и onoy загружает отладочную информацию для основного bpl), вуаля, мой стек и локальные переменные отображаются правильно. В том же бинарнике. Когда я включаю «загружать символы для неуказанных модулей», я возвращаюсь к старой ситуации с отсутствующим стеком и локальными символами.

Поэтому я подозреваю, что существует ограничение на объем отладочной информации, который может обрабатывать отладчик (действительно? в 64-битном режиме?), который я, кажется, помню из давней Delphi 2. .7 отладка.

Конечно, при этом мне не хватает отладочной информации для всех других модулей, поэтому, хотя это ответ, это НЕ окончательное решение. Я добавлю еще один вопрос и вопрос на сайте embarcadero.

введите здесь описание изображения

person H.Hasenack    schedule 29.06.2018
comment
Я также нашел эту связанную проблему на сайте embarcadero, и там упоминалось, что вы также можете использовать подстановочные знаки для загрузки таблиц символов. Муравей работает как шарм, чтобы обойти проблему без необходимости указывать каждый bpl, который я использую. quality.embarcadero.com/browse/RSP-10080 - person H.Hasenack; 29.06.2018