Eklatante Probleme mit Debuggen

[freimatz]

Hallo zusammen,
wir (ca. 10 Entwickler) haben seit Jahren Probleme mit dem Debuggen, seit einiger Zeit sind diese eklatant. Es äußert sich so, dass der Debugger bei Breakpoints nicht mehr anhält. (Auch gibt es keine blauen Punkte.)

Das Problem tritt nicht immer auf. Es gibt jedoch bestimmte Packages, bei denen es in 98% der Fälle so ist. Wir behelfen uns dann mit Logging über CodeSite, das ist jedoch Programmieren wie vor 30 Jahren.
Das Problem in einem abgegrenzten Umfeld zu reproduzieren ist uns noch nicht gelungen. Wir arbeiten derzeit mit 64-Bit, Delphi 11.3, es gibt mehr als 100 Module und mehrer Millionen Zeilen Quellcode.

Wir haben inzwischen ein umfangreiches internes Dokument mit Anleitungen was man alles versuchen kann, damit das Debuggen geht. (Build nur als Release und nur benötigte Module mit Debug, Löschen von rsm-Dateien, Delphi neu starten, Option "Load all Symbols" aus und Module explizit angeben, anderes Startprojekt, etc. ...). Das hilft oft nach einigen Versuchen, ist aber extrem hinderlich. Und bei dem oben erwähnten Modulen hilft es eben gar nicht.

EMB ist leider auch nicht sehr hilfreich.
Der Support hatte einen Fall mal analysiert und einen Workaround (anderes Startprojekt). Ein Fehler in einem Log wurde nicht weiter thematisiert. Der Support weigert sich ausserdem bei uns per Videotool reinzuschauen - aus irgendwelchen datenschutzrechtlichen Gründen. Ohne ein konkretes reproduzierbares Problem ist auch nicht etwas zu erwarten.
Marco Cantu und David Millington wissen Bescheid. Es wurde mal geschrieben, dass Verbesserungen beim Debugger in einer nicht näher spezifizierte Zukunft angestrebt seien. Weitere Hilfeanfragen blieben unbeantwortet.

Habt Ihr noch eine Idee was wir da machen könnten?

In der Zwischenzeit rate ich davon ab Delphi für neue unternehmenskritische Projekte zu verwenden. Es geht zwar wohl meistens gut, wenn man aber in diese Situation kommt, wird es kritisch.

[jaenicke]

Ein Bekannter hatte ebenfalls einige Probleme beim Debuggen. Auch da fehlt immer wieder der Zugriff auf die Debuginformationen, so dass er keine Haltepunkte setzen kann usw., was sich also ähnlich anhört.

Meine Idee war, den Remote Debugger zu verwenden. Das hat dann auch geklappt. Da ließen sich die Haltepunkte normal setzen, debuggen, alles lief. Sprich er hat einfach lokal den Remote Debugger gestartet und verwendet dann "Prozess laden" mit 127.0.0.1 als Host zum Debuggen. Das ist zwar nicht ideal, funktioniert bei ihm aber deutlich besser als direkt mit dem Debugger.

[mytbo]

Zitat von freimatz:

Habt Ihr noch eine Idee was wir da machen könnten?

Für das Problem mit dem Debuggen hat Sebastian einen möglichen Weg beschrieben. Wenn du am Logging interessiert bist, ist mORMot einen Blick wert. In diesem Thread habe ich etwas dazu geschrieben.

Bis bald...
Thomas

[himitsu]

Wobei bei Win64 doch intern eigentlich sowieso der RemoteDebugger benutzt wird.

[jaenicke]

Gut, in dem Fall war es 32-Bit. Ob es bei 64-Bit einen Unterschied macht, weiß ich nicht.

[bobokonijn]

Was für mich gut funktioniert in solchen Fällen ist den Debugger erst *nach* Programmstart mit dem Programm zu verbinden (Run-> Attach To Process). Ggf muss man im Programm eine Messagebox einbauen damit das Programm absichtlich anhält und man die Zeit hat, den Debugger zu verbinden.

[jaenicke]

Zitat von bobokonijn:

Was für mich gut funktioniert in solchen Fällen ist den Debugger erst *nach* Programmstart mit dem Programm zu verbinden (Run-> Attach To Process). Ggf muss man im Programm eine Messagebox einbauen damit das Programm absichtlich anhält und man die Zeit hat, den Debugger zu verbinden.

Oder:

Delphi-Quellcode:

while not  IsDebuggerPresent do
  Sleep(10);

Das funktioniert auch bei Diensten.

[dummzeuch]

Zitat von jaenicke:

Zitat von bobokonijn:

Was für mich gut funktioniert in solchen Fällen ist den Debugger erst *nach* Programmstart mit dem Programm zu verbinden (Run-> Attach To Process). Ggf muss man im Programm eine Messagebox einbauen damit das Programm absichtlich anhält und man die Zeit hat, den Debugger zu verbinden.

Oder:

Delphi-Quellcode:

while not  IsDebuggerPresent do
  Sleep(10);

Das funktioniert auch bei Diensten.

Interessante Methode, aber sie birgt die Gefahr, dass man einfacher vergessen kann, es wieder zu löschen. Dann wundert man sich, weshalb das Programm hängt, kann das aber im Debugger nicht nachvollziehen, und sucht sich einen Wolf, nur um am Ende mit dem Kopf auf der Tischkante zu landen, wenn man seine Dummheit bemerkt hat.

[jaenicke]

Das ist natürlich richtig, aber wenn man alle Änderungen überprüft und z.B. vor und nachher ein paar Leerzeilen und/oder eine Compilerwarnung einfügt, kann das kaum passieren.

Im Dienst fällt mir z.B. gar keine andere sinnvolle Variante ein, wenn man den Start des Dienstes debuggen möchte.

[himitsu]

Da der normale Code des TService sofort wieder stoppt, wenn das Programm nicht aus dem Service-Host gestartet wird, hatte ich den Code mal etwas nachgebaut.
Dann noch ein kleines Dummy-Fenster, damit man den Dienst "sieht" und was Einfaches zum Beenden hat.

Somit lässt es sich auch einfach über Debugger oder normals starten. (beim Kunden auch mal "manuell" und mit einigen Logausgaben im Consolenfenster, falls es dort mal wieder Probleme beim Starten gibt)
Wenn nur über Debugger, dann ginge auch IsDebuggerPresent, aber hier einfach mit einem Parameter gelöst, damit es auch einzeln starten kann.


Das TService vom Windows ist eh etwas "beschränkt".
z.B. läßt sich der Dienst nur einmal registrieren&installieren (außer man schmuggelt z.B. noch einen Start-Parameter mit rein)