F7-Debuging hängt oft

[stahli]

Ich will das Problem (mit D12) erst mal allgemein erläutern:

Wenn ich von einem Haltepunkt mit F7 debuggen will, hängt sich das Projekt sehr oft auf.
Setze ich in der aufzurufenden Funktion jedoch zuvor einen Haltepunkt, hält der Debugger dort auch an.
Das Aufhängen geschieht jedoch auch beim Rücksprung aus Funktionen oder bei Zuweisungen an Result.
Ich muss dann das Debugging abbrechen und neu versuchen, ggf. mit neuen Haltepunkten.

Ich arbeite mit einigen Threads. Vielleicht ist da ja nicht alles in Ordnung?

Kann jemand dieses allgemeine Problem irgendwie einordnen?
Hat jemand eine Idee, wo ich mal genauer schauen muss?

[himitsu]

Dieses Problem mit F7/F8 hatte ich schon in XE, zu oft auch schon in 10, sowie in 11 ... nur in der 12 erst zwei Mal. :stupid:

Auch F9 und zu schnell gleich wieder Strg+F2, weil "mist, noch was vergessen ...", da kracht gern der Debugger so hart weg, dass Delphi hängt oder wenn es noch reagiert, es beim Beenden dann abraucht, weil es den Debugger unbedingt beenden will, welcher aber schon weg ist.

[stahli]

Also Delphi hängt nicht komplett.
Mit Ctrl-F2 oder dem roten Button kann ich den Debugger und das Projekt noch abbrechen.

[himitsu]

Ja, meistens lässt sich Dieses hier noch mit Stop (Strg+F2) beenden
und nur selten bleibt es danach komplett hängen. (zumindestens seit 10.2)

Es ist so oder so aber extrem nervig, wenn man sich schon viele Minuten durch einen Code gedebuggt hatte,
es dann hängt und man deswegen aufgeben darf.

Noch schlimmer ist es, wenn dann auch noch die IDE hängt oder spurlos verschwindet,
denn "Alles speichern" speichert nicht alles ... vor allem nicht den Desktop (geöffnete Dateien und Haltepunkte)



Ganz tief im DevExpress-Grid, PgDAC oder Eurekalog verlaufen, so dass man mit F7/F8 nicht mehr raus findet, und dann verzweifelt F9 ... da ist der Debugger auch schon paar mal komplett verreckt. Meistens Oftmals konnte ich dann noch speichern, aber kurz danach blieb auch gern dann die ganze IDE hängen.

[Kas Ob.]

Zitat:

Zitat von stahli (Beitrag 1530234)

Ich will das Problem (mit D12) erst mal allgemein erläutern:

Wenn ich von einem Haltepunkt mit F7 debuggen will, hängt sich das Projekt sehr oft auf.
Setze ich in der aufzurufenden Funktion jedoch zuvor einen Haltepunkt, hält der Debugger dort auch an.
Das Aufhängen geschieht jedoch auch beim Rücksprung aus Funktionen oder bei Zuweisungen an Result.
Ich muss dann das Debugging abbrechen und neu versuchen, ggf. mit neuen Haltepunkten.

Ich arbeite mit einigen Threads. Vielleicht ist da ja nicht alles in Ordnung?

Kann jemand dieses allgemeine Problem irgendwie einordnen?
Hat jemand eine Idee, wo ich mal genauer schauen muss?

Very annoying indeed, it make me angry so i limit my use for Step-Into (F7) a lot and replace it with breakpoints and F8.

Yes it is because of threading, and it is a bug in the debugger, i rarely observed this with main threads, most the time happens with the last created threads !, yet it happen in the main sometimes, this doesn't mean you threading code is problematic, it is the debugger fault.

From my observation, the OS sometimes create its own threads while you application is running, some of them finish and some stay running, these are responsible for many things, from checking compatibility to drawing to handling security.... etc, and they are irrelevant for us,
Now to details, the problem is with the debugger because it does hook creating threads and exiting process wide, so it try to keep track of them and get all threads state (paused/running), that is OK and in fact that is crucial job for the debugger to do, so when you click stop or the execution hit a break point (or exception...) it will pause all threads including the OS threads (the externals), here comes the problem if the OS recreated another threads or terminated/killed his own threads, the debugger in this case specially with F7 (Step-Into) fail to repopulate/update his list of threads for each Step, and will fail to resume one thread or fail to stop one, or just find one in his list that is not there and fail to coup with that.

This happen more often of you are debugging hot code, means if the application was running for few minutes and entered some idle/stable state then you will not witness this, because external threads are very rare after these first few minutes from starting the debugged process, but this is more annoying to wait few minutes to debug what really need to be found this moment !

Hope that helps, and hope you can continue digging this, over time this annoyed me so much, so i either very rarely use F7 or i use x64dbg, a real debugger from https://x64dbg.com/

[Neutral General]

Das passiert allerdings immer nur 1 Step vor der entscheidenden Zeile, 7 Ebenen tief im Callstack.

[jbg]

Meine Vermutung ist, dass Embarcadero den IDE FixPack Patch "Usage of a hash table for file-to-unit resolution if the debugger requests the symbols for a file. (Step into/over became a lot faster)" nicht übernommen hat.

[stahli]

Vielen Dank an alle.
Einen externen Debuger einzusetzen, ist für mich leider etwas zu anspruchsvoll.

Vielleicht kann ja Emba das Problem einmal anschauen...

[freimatz]

Verwendest Du spezielle Laufwerksbuchstaben? (Netzwerk, Subst, mklink,...)

[Sherlock]

...oder Umlaute im Projektpfad?

https://quality.embarcadero.com/browse/RSP-15908

[stahli]

Ich verwende nur die Standardordner und keine Sonder- oder Leerzeichen.

Ich habe mal einen Supportfall eröffnet. Mal sehen, ob es etwas bringt (ich kann das Problem ja auch nicht weiter eingrenzen).

[stahli]

Der Support war nett und bemüht und ich will versuchen, den Stand mal zusammenzufassen.

1)
Ich habe ein Package erhalten, das die Threadkontrolle (Debug-Fenster der Threads) in der IDE ausschaltet.
Das war aber nicht hilfreich.

2)
Mir ist aber bei Erstellung eines Testprojektes aufgefallen, dass ich in meinem Realprojekt den Projekteigenschaften "Compilieren: mit Debug-DCUs" ausgeschaltet hatte weil ich nicht die Systemdateien sondern nur meine Projektdateien debuggen will.
Ist die Option angewählt (Standard) dann verzweigt der Debugger mit F7 in verschiedene Systemunits, kommt aber wieder zum Projekt zurück.
Ist die Option aber abgewählt UND sind Threads aktiv, dann hängt sich der Debugger oft auf.
Hier ein Link zu dem Testprojekt, Exe und kurzes Video: https://1drv.ms/u/s!Arw_fIE7GaOPiNAr...G60lw?e=Z5gppj (hier zu groß als Anlage)

3)
Der Support hat das so bestätigt (auch für frühere Delphi-Versionen) und eine interne Fehlermeldung eingetragen. Offenbar kann er selbst nicht wirklich sagen, was draus wird und wann/wie das bereinigt wird.

Eine zwischenzeitliche Info habe ich nicht verstanden:

Zitat:

It looks like it because the exe is being built without packages, if you build it with packages it should not be an issue.

The fact that you have the package code in the same directory as the EXE code is a problem, when the EXEs are linked rebuilds uses the dcus built for the packages. The packages and code should be in separate folders.

Your other option is not use the packages but then do not build the packages as part of your dependencies.

Ich habe ja Packages verwendet.
Er hat dann das Projekt ohne Packages umgestellt, so war es aber nicht komplett funktionsfähig.

Zitat:

For me I cannot get it to hang? I moved the packages and their code into their own directories and changed the EXE to use packages and not statically link as this will force the linker to use the packages' DCP files instead of the DCUs and then it works.

It is still a bug, but I need to look at it with fresh eyes in morning to see if I can make more sense of what is causing this behaviour.

Ich kann die Aussage nicht einordnen. Für mich ist das irgendwie widersprüchlich.

Na gut, letztlich hat er es als Bug eingestuft, was schon mal mehr ist, als ich erwartet habe.
Für die Fehlerbereinigung ist er dann aber nicht mehr zuständig, soweit ich verstanden habe.