Debugger bricht einfach ab

[Ralf Kaiser]

Halli Hallo,

Ich habe da ein Projekt bei dem ich plötzlich nicht mehr debuggen kann.

Bei dem Betreffenden Programm sind alle "BlueDots" vorhanden. Wenn der Debugger startet dann wird das Programm nach ganz kurzer Zeit Plötzlich ohne Fehlermeldung beendet. Ich bin im Moment noch dabei die entsprechende Stelle zu ermitteln.

Wenn ich das Programm normal starte und mich mit den Debugger dann "dranhänge" wird das Programm und der Debugger ebenfalls kommentarlos beendet.

Bis vor einer Woche hatte ich dieses Problem noch nie. Auch ist der Quelltext des Programmes ganz frisch aus der Versionsverwaltung geholt worden. Auf anderen Rechnern, mit der selben Delphi-Version, kann problemlos debuggt werden.

Wenn ich das Programm mit einer anderen Delphi-Version debugge habe ich ebenfalls keine Probleme.

Hat jemand eine Idee, wo man da ansetzen könnte? Es scheint ja nicht am Programm zu liegen da das debuggen auf anderen Rechnern und auf meinem Rechner mit einer anderen Delphi-Version debugbar ist.

D2010 (alle Updates) auf meinem Rechner - kein Debuggen
D2010 (alle Updates) auf anderen Rechnern - keine Probleme
DXE3 und DXE4 (auf meinem Rechner - keine Probleme

Danke schon mal,
Ralf

[stahli]

Hast Du vielleicht eine Ordnerkopie Deiner Quellen erzeugt?

C:\...Projekte\...
C:\...Projekte (Kopie)\...

So etwas kann die IDE und/oder den Compiler sehr durcheinander bringen.

[Ralf Kaiser]

Nein. Pfade usw. sind vollkommen OK. Wie gesagt: Auf einem anderen Rechner (mit identischem "Pfaddlayout") lässt sich problemlos debuggen. Auf meinem Rechner mit anderem Delphi (kompiliert aus dem selben Verzeichnis, nur anderes Ausgabeverzeichnis) lässt sich ebenfalls problemlos debuggen.

Ach ja, noch was sehr wichtiges vergessen: Auf meinem "Problem-D2010" lassen sich alle anderen Projekte (ca. 70 Stück, gemischt DLLs, BPLs und Exen) ebenfalls Problemlos debuggen!

[Stevie]

Hast du schon dafür gesorgt, dass nicht irgendwo noch dcus oder andere Reste rumliegen?
Handelt es sich um eine exe oder eine dll/bpl, die erst von einer anderen Host Anwendung geladen wird?
Bei dll/bpl solltest du sicherstellen, dass sie nicht geladen, entladen, geladen wird, denn in einem solchen Fall steigt der Debugger in aller Regel nach dem entladen aus und du kannst nicht nach dem 2. Laden wieder einsteigen (in solchen Fällen den Debugger später an den Prozess anhängen)

[Ralf Kaiser]

Ja. Das habe ich alles schon kontrolliert. Es handelt sich um ein EXE-Projekt das auch keine DLLs oder BPLs verwendet. Im Moment bin ich etwas ratlos.

Um weiter arbeiten zu können habe ich gerade alles nochmal neu auf DXE3 kompiliert und kann jetzt wenigstens debuggen. (wir können leider die nicht die gesamte Projektgruppe offiziell auf DXE3 oder DXE4 laufen lassen da vor der Umstellung noch einiges getestet werden muss)

[Ralf Kaiser]

Mittlerweile habe ich zumindest die Stelle gefunden an der der Debugger einfach das Programm beendet:

Es gibt da eine Interface-Variable mit der an einer Stelle gearbeitet wird. Diese wird lokal in einer Methode erzeugt. Wenn die Methode beendet ist geht diese Variable out of Scope und wird freigegeben und wenn der Destructor der Klasse die hinter dem Interface steckt das letzte "inherited" ausführt dann bricht das Programm ohne jegliche Meldung ab. Das "inherited" sollte eigentlich den Destructor von TInterfacedObject aufrufen aber genau an der Stelle beendet der Debugger sich und das Programm.

Weder auf anderen Rechnern mit D2010 noch auf meinem Rechner mit anderer Delphi-Version passiert das. Und bei meinem Rechner passiert dies auch erst seit kurzem.

:gruebel: :gruebel: :gruebel:

Ich habe weiterhin keine Idee, was sich bei meiner D2010-Installation geändert haben könnte was dieses Verhalten auslöst...

[rwalper]

Hast Du vielleicht eine weitere Delphi-Version auf dem Rechner?

Dann könntest Du versuchen, die borlndmm.dll aus dem Delphi-Bin-Verzeichnis in das Verzeichnis Deiner exe zu kopieren.

[Ralf Kaiser]

Wir verwenden als Memorymanager FastMM4. Allerdings habe ich den auch schon ausgeschaltet - mit dem selben Ergebnis.

Na ja, der Teil der Anwendung in dem dieses lästige Phänomen auftritt lässt sich über Optionen deaktivieren. So kann ich im Moment erst einmal weiter debuggen, da die betroffene Codestelle niht ausgeführt wird (lustig wird es erst wenn ich an dem Programmteil mal was ändern mus... :roll: )