Delphi-App hat "Keine Debug-Info" beim Debuggen

Wir haben gebaut, eine Anwendung, die Pakete und Komponenten. Wenn wir die Anwendung Debuggen, die "Ereignis-Log" in die IDE zeigt oft den unseren BPLs geladen werden, ohne die debug-Informationen ("Keine Debug-Informationen"). Ist dies nicht sinnvoll, da alle unsere Pakete und EXEs sind gebaut mit 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

Wir haben 4 Projekte, die alle gebaut mit Laufzeit pacakges:

Kern.bpl
Komponenten.bpl
Plugin.bpl (beide #1 & #2)
MainApp.exe (verwendet #1)

Probleme Beobachtet

1) Viele Male, wenn wir debug-Komponenten.bpl ist geladen mit debug-Informationen, aber alle Werte in der "Lokalen-Variablen" - Fenster leer. Wenn Sie Schwebeflug Ihre Maus über einer variable im code, es gibt kein popup, und Bewerten Fenster zeigt auch nichts an (die "Ergebnis" - Bereich ist immer leer).

2) Manchmal ist das Ereignis-Log zeigt "Keine Debug-Informationen" für verschiedene BPLs. Zum Beispiel, wenn wir das Plugin aktivieren.bpl-Projekt und setzen Sie den Run | Parameter die Host-Anwendung auf die MainApp.exe und dann F9 drücken, werden alle Module scheint, zu laden mit "Hat" Debug Info", außer für das Plugin.bpl-Modul. Wenn es lädt, wird das Ereignis-Log zeigt "Kein Debug Info". Allerdings, wenn wir die app schließen und sofort F9 drücken, wird es wieder laufen, ohne alles neu zu kompilieren und das Zeit-Plugin.bpl ist geladen mit debug ("Hat" Debug Info").

Fragen

1), Was bewirken würde, dass die "Lokale Variablen" - Fenster zu nicht die Werte anzuzeigen?

2) Warum sind die BPLs manchmal geladen ohne debug-Informationen, wenn die BPL war erfüllt mit debug und all die debug-Dateien (dcu, Karte, etc.) sind verfügbar?

InformationsquelleAutor James L. | 2012-01-09

4

Wir haben festgestellt, ein ähnliches Problem in unserem Projekt. Leider haben wir Dutzende von bpl, so können wir Sie Zusammenführen in einem.
Diese Ausgabe erschien, nachdem wir migriert XE2 geändert und die Ordner-Struktur unserer Kompilier-Ziel.
Während es schwierig ist, zu sagen, ob neuere Versionen von Delphi eingeführt, die das Problem sind oder nicht, wir konnten das Problem beheben, indem Sie hinzufügen den Ordner, wo die bpls sind zusammengestellt in der path-Umgebungsvariablen. Mit dem Pfad-override-Funktion der IDE. Diese Art der Konfiguration war nicht notwendig, in Delphi 2010...

InformationsquelleAutor Yoann
4

Ich würde es beschreiben, mein Problem mit ihm.

Ich dynamisch laden " - Paket mit LoadPackage Funktion.

Kann ich sehen, in SysInternals.com Process Monitor dass packagename.DCP habe öffnen und Lesen succesfuly nach LoadPackage verarbeitet - kein Datei-I/O ist fehlgeschlagen, kein Versuch, es zu finden, am falschen Ort, nichts verdächtiges. Vielleicht gibt es also etwas konstruieren, DCP, das macht IDE-debugger Nüsse gehen. Ich Sehne mich nach Zeiten, als Turbo Debugger war für Delphi.

BTW, dasselbe gilt für das packagename.RSM ist eine erstellt.

Dann (bei Pause am Haltepunkt oder Schritt-Trace) ich öffne Ansicht /Debug-Fenster /Module und Letzte Modul ist von mir - und es ist leer "symbol information" der Zelle. Ich mit der rechten Maustaste klicken, wählen Sie " "Re-load symbols" Aktion - und hier ist es, ab jetzt kann ich die debug.

PS. Keine Ahnung, ob mir das helfen würde, um debug-Initialisierung Abschnitte aber - hoffentlich "break on load Menüpunkt" arbeiten würden, auch mit dynamischen LoadPackage Anrufe...

PPS. Es funktioniert tatsächlich, sogar über IDE neu gestartet. So, jetzt bin ich alarmiert BPL laden mit CPU View ich Schlag CTRL+ALT+M scrollen Sie nach unten zu finden, mein BPL-r-klicken Sie auf Reload Symbols drücken Sie die EINGABETASTE schließen Sie dann Modules und CPU Ansichten und Streik F9 (Run). Nach initialization Abschnitte vervollständigt bin ich wieder alarmiert durch CPU View - nur wenige JMPs vor der Ausfahrt aus LoadPackage - so schließe ich CPU View und stike F9 noch einmal. Ziemlich mühsam, aber immer noch besser als IDE neu starten.
- Nicht zu beantworten, warum debug-info fehlt, aber +1 für den hilfreichen workaround. Das ist viel besser als Neustarten von Delphi und versucht wieder und wieder, bis es dann endlich funktioniert.
- es fehlt nicht, es ist in der BPL - CFF-Explorer zeigt diese. die Tatsache ist, dass die IDE nicht verwenden - er verwendet die DCP-Datei statt. Und wenn es mehrere DCP-Dateien - dann schlägt es fehl. Aber warum es manchmal nicht, auch wenn das nur DCP vorhanden und deutlich zu Lesen, dass die Datei ok - das ist das Geheimnis. In meinem Fall fand ich eine gleichnamige Einheiten EXE : Pfad1\name und BPL1 : Path2\ - name - allerdings BPL1 und BPL2 loadedokay und nur dynamisch geladen BPL3 betroffen war. Trotzdem, SysInit Gerät geklont werden, die in EXE/DLL/BPL-Dateien, so dass, sollten Sie nicht verwechseln IDE debugfer. Mistery. PS thx 2u-für die Feststellung Module anzeigen
- Du bist willkommen-aber ich habe nie versucht, Rechtsklick zu sagen, es zu "reload-Symbole". Das ist ein netter neuer trick.
- ich Frage mich, ob es automatisiert werden kann, von OTA 🙂
- Lange nicht gesehen, James. Ich habe gerade festgestellt, dass, während ich hatte XE2 Upd4 HF1 installiert, in Windows\System32, die ich hatte rtl160bpl und vcl160.bpl von einigen vorherigen version 2011 (update1 ? weiß nich). So porgram kompiliert gegen RTL/VCL in c:\RAAD Studio\9.0\... und wurde ausgeführt und debuggt gegen eine andere BPL-Versionen. Dass auch eine Menge Probleme, wenn debugigng im inneren RTL, evaluatning variable.classname und so. Ich löschte diese älteren global BPLs und für ein paar Stunden dieses Problem nicht wiederholt. Hoffentlich würde es nicht wieder auftreten oder tun würde, viel seltener
InformationsquelleAutor Arioch 'The
4

Diese nicht-offizielle tool behebt viele Probleme, die mit Delphi. Es fixiert das Modul laden, ohne debug info für mich. Alle credits zu magicandre1981.
- Ich hatte ein Problem mit dem Debuggen design packages in Delphi XE6 IDE nicht laden wollen, debug-info. Dieses tool geholfen, danke!
- Ich war auch die Landung auf der " CPU " - Registerkarte jedes mal, wenn ein Haltepunkt getroffen wurde -> mein bpl und die app geladen wurden ohne Debug-Informationen. Ich installierte das tool und es funktionierte einfach. Thx!!!
InformationsquelleAutor Danatela
2

Bauen Sie Ihre separate Pakete mit debug-Informationen an, und Sie schließlich wollen, Sie zu bauen, ohne debug auch - so haben Sie beide in 2 spots. Dann wollen Sie bauen Ihr app-Projekt mit debug-info. Überprüfen Sie Ihre Wege, um sicherzustellen, dass Sie sind, einschließlich der debug-Paket aktiviert Quelle in Ihrem debug-Projekt baut. Es klingt wie Sie werden können, einschließlich der Pakete, die gebaut wurden, ohne debug, weil Sie von der falschen Quelle. Sie haben zu stellen Sie sicher, dass Sie nicht beide Wege enthalten ist, verlassen, Delphi, zu wählen, was zu zählen, wenn er die gleiche Paket in beiden stellen.
- Alle unsere Projekte werden gebaut, mit debug und den beiden DEBUG und RELEASE die gleiche output-Ordner. Es ist also nicht ein problem mit den Paketen gebaut, allerdings ohne DEBUG oder dass der debugger findet die RELEASE-Versionen von jedem der Pakete... Wir werden das überprüfen der Pfade, obwohl, um sicher zu sein, dass die debug-DCUs werden richtig gefunden. Vielen Dank für die Anregungen.
- +1 für deinen Vorschlag, überprüfe die Pfade. Dies führte mich zu öffnen Sie das Debug-Fenster Module, die zeigt, wo die debug-Symbole geladen werden. Dies hat geholfen, die führen mich auf die Idee, dass das Problem gelöst (siehe Antwort unten).
InformationsquelleAutor Patrick Moloney
2

Für unsere Besondere situation, in der wir waren in der Lage, das Problem zu beheben durch die Kombination der Kern.pbl und Komponenten.bpl in eine einzige BPL. Jetzt alle Module geladen sind, mit debug-Infos und die gelegentliche Problem, wo das Fenster nicht angezeigt Werte für die Variablen ist gelöst.
- Kombinieren Sie die BPLs, um loszuwerden, das problem ist nicht eine gute Lösung. Stell dir vor, Sie haben hundert von dynamischen Paketen, ist es unmöglich, Sie zu vereinen in einer einzigen BPL.
- Wir haben Dutzende von anderen BPLs. Es war gerade die Trennung dieser beiden, die das problem verursacht. In unserem Fall, die Kombination dieser beiden war akzeptabel--, während die anderen Dutzende trennen... Es hatte etwas zu tun mit den Komponenten.bpl hing stark auf Core.bpl.
- Haben Sie optset Referenz für beide debug und release Konfiguration?
- Ich habe eine neue Antwort, die helfen können, das problem zu lösen.
InformationsquelleAutor James L.
2

Dieses problem könnte sein, rund um QC#109291:

Bei der Delphi-IDE-start vorstellen .dproj-Datei und erstellen Sie die Konfiguration mit der option-sets, Sie verbessern die Projekt-release-management-eine ganze Menge.

Aber es hat auch einen Nebeneffekt, ist schwer zu wiederholen und zu fangen, und ich dachte, es war Fehler in der IDE. Sollte das problem immer verwirren die Nutzer, wo einige Projekt ist nicht in der Lage zu Debuggen, die sich im IDE-debugger. Auch wir überprüfen alle relevanten Einstellungen der compiler-und linking-Optionen im Projekt, wird der debugger nicht aktiviert an dem Projekt. Einige Projekt arbeitet und einige Projekt nicht. Wir haben sogar Zusammenhang ist sein problem mit dem Arbeitsspeicher oder cpu-problem.

Merke ich, das problem ist wegen der .dproj Datei-Einstellung speichert keine richtigen Informationen. Wenn die verwandten .dproj-Datei hat so etwas wie dieses:
```
<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>
```
Den Release.optset binden Cfg_2 und Debug.optset binden Cfg_1 aber Release Konfiguration ist mit Cfg_1 und Debug Konfiguration ist mit Cfg_2.

Wenn Sie das Projekt erstellen, wird die debug-info wird nicht erzeugt in der debug-Konfiguration, sondern erzeugen auf der release-Konfiguration.

Einen workaround-Lösung ist offen .dproj mit einem beliebigen text-editor, aber nicht die Delphi-IDE, und update:
```
<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>
```
- Das sieht vielversprechend aus, aber ich werde nicht in der Lage sein, um es zu testen, bis ich laufen in einer situation wieder, wo die debug-Informationen fehlen. Vielen Dank für das teilen Ihrer Erfahrung.
- Wahr. Ich löste viele Probleme, die durch das löschen der dproj-Datei und lassen Sie Delphi regenerieren es. Eines der vielen Beispiele: stackoverflow.com/questions/21958575/...
InformationsquelleAutor Chau Chee Yang
0

Fand ich in der .dprj Datei eine Zeile in der Cfg_2 détails mit Wert Debugger_LoadAllSymbols, die auf false festgelegt wurde. Ich habe es eingestellt auf "true". Das Problem ist gelöst. Vielleicht nicht vergleichbar mit deinem Fall, aber kann helfen.
```
<PropertyGroup Condition="'$(Cfg_2_Win32)'!=''">
...
    <Debugger_LoadAllSymbols>true</Debugger_LoadAllSymbols>
...
</PropertyGroup>
```
InformationsquelleAutor

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.