DLL debuggen

[himitsu]

Nee, die IDE ist zumindestens seit 10.2 beim Compilieren nicht mehr verreckt.
In XE mußte ich die Projektgruppe in 2-4 Teilen kompilieren, sonst krachte alles mit OutOfMemory, wenn zuviele Projekte auf einmal.

Wenn ich die DLL debugge, egal ob die EXE vorher neu kompiliert oder nicht, hab ich in D12 jetzt zuverlässig immer

Zitat:

Thread-Start: Thread-ID: 17328. Prozess Scripting.exe (8064)
Prozessstart: C:\Develop\ActiveScripting\Win32\Debug\Scripting.e xe. Basisadresse: $00EC0000. Prozess Scripting.exe (8064)
Modul laden: Scripting.exe. Ohne Debug-Infos. Basisadresse: $00EC0000. Prozess Scripting.exe (8064)
Modul laden: ntdll.dll. Ohne Debug-Infos. Basisadresse: $77AA0000. Prozess Scripting.exe (8064)

In der 11.3 war es ab und an mal so, dass da auch die Debuginfos geladen wurden und ich EXE sowie DLL gleichzeitig debuggen konnte.

Die Prozeduren mit StackFrame findet er noch, aber dann steht nur mehrmals der EXE-Name im Stacktrace, anstatt der Prodzedurnamen.

[himitsu]

Kennt sich irgendwe gut mit dem Debuggen und den Einstellungen für DebugInfos aus?


Der einfache Fall geht ja inzwischen "öfters mal".

aber ich wollte hier nun in D11 das auch endlich mal zum Laufen bringen (wir suchen grade in pgDAC einen Fehler).
* Delphi sagt es würde die Debuginfos laden -> Modul laden: dac150.bpl. Enthält Debug-Infos. Basisadresse: $016B0000. ...
* aber weder im Stacktrace noch in den Units ist davon was zu sehn (so als wenn er sie dann nicht benutzen würde)
Sowohl in XE, als auch in 11.3 will das einfach nicht.
Es ist auch egal ob interne oder externe TDS (auch RemoteDebug noch aktiviert gehabt).


* FremdKomponenten werden mit FinalBuilder kompiliert -> Delphi-Action, also DCC32
* eigene BPL/DLL/EXE wurden in XE auch mit Delphi-Action und Eurekalog kompiliert, also ECC32 zu DCC32
* eigene BPL/DLL/EXE werden in 11.3 nun mit MSBuild kompiliert -> intern DCC32 und im AfterBuildScript der ECC

Bei den eigenen Projekten BPL/DLL/EXE funktioniert es in 11.3 nun recht gut (in XE mußten BPLs nochmal im Delphi kompiliert werden, damit DebugInfos funktionierten ... doppelte Configs und im FB mit Fehlern/Unterschieden)

Aber bei den FremdKomponenten bekomm ich es einfach nicht zum Laufen, dass ich Diese debuggen kann.
Es macht auch keinen Unterschied, ob deren Projekte in der geladenen Projektgruppe drin sind.


Früher wurden viele Packages wild über Suchpfade geholt ... inzwischen alles im EXE-/Arbeitsverzeichnis (Testsystem so wie auch bei den Kunden)
vor allem da XE und 11 parallel sich mit gleichnamigen Dateien in den Suchpfaden in die Quere kam.

[Sinspin]

Ich sag nur MadExcept, das löst 99.9% aller dieser Fragen in Luft auf.
Es gibt zwar noch immer Fälle wo was daran vorbei kracht. Gerade wenn es um eine nicht Delphi dll geht, aber alles in allem ist das schon eine feine Sache.

[himitsu]

Dort ist ein Eurekalog drin, in diesen Packages.

[Kas Ob.]

I am not sure that understand half of the former posts due the translation.

And sorry if that i am missing the point.
This line brings me to something i saw in either D2009 and D2010 years back, (or it was D2010 and XE5, i really can't remember)

Code:

Process start: C:\Develop\ActiveScripting\ Win32 \Debug\Scripting.e xe. Base address: $00EC0000. Process Scripting.exe (8064)
Load module: Scripting.exe. Without debug information . Base address: $00EC0000. Process Scripting.exe (8064)

The problem was that : EXE is not in the same folder as the dpr while the dpr of the EXE and the DLL in the ProjectGroup.

On other hand i will check and make sure to disable all Debug information handling in EurekaLog for these projects, it might introduced some regression, or test an older stable version, because EL does restructure the EXE, and could did mess something.

[Kas Ob.]

There is also something to try, move both the EXE and DLL into one folder and make sure the IDE doesn't have any opened projects, then debug from there or attach to running process.

[himitsu]

Ja, beim ursprünglichen Test hier, ging es nur um eine EXE und eine DLL, wo einfach immer alles gedebuggt werden sollte.
Aber grundsätzlich sollte es auch für alle anderen Projekte möglich sein.


Wir haben fast 100 eigene BPL/DLL/EXE (werden im FinalBuilder oder Delphi kompiliert)
und dazu noch 47 BPL und einige DLL für Fremdkomponenten, plus weitere 238 BPL vom DevExpress, welche durch den FinalBuilder erzeugt werden.
Seit unserem neuen FB-Script für D10 D11+, mit externen TDS, damit die DebugInfos sich standardmäßig einfach entfernen lassen (aber auch mit internen TDS probiert),
weil "normal" will man beim Debuggen seinen eigenen Code durchgehn, oder nur den Code einer bestimmten Komponente, und sich nicht andauernd in Fremd-Code verlaufen.

Im Moment hoffe ich noch, dass irgendwo einfach nur eine Option falsch steht, weswegen es garnicht geht.
Bei einem Teil geht es ja inzwischen, wo mit MSBuild gearbeitet wird, gegenüber den manuellen DCC32.

Es muß doch irgendwie möglich sein, dass man ohne ständiges Rumgepfusche einfach so debuggen kann, indem man im Delphi auf F9 drückt und anschließend alle vorhandenen Debuginfos benutzt werden. (das Log sagt ja, dass die Infos vorhanden sind)