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