Debug-Bug ?

[stahli]

Ich habe ein Problem beim Debuggen.

An einem bedingten Haltepunkt wird mit F8 statt schrittweise Debuggen "weiter ausführen" (F9) ausgeführt.
Video: https://youtu.be/yTVGrz3I-nk

Kennt Ihr sowas?
Normal sollte das ja nicht sein...

Ich könnte ggf. mal versuchen, das in einem kleinen Testprojekt nachzustellen und zu melden.

[himitsu]

Eigentlich sollte er hier vor Auswertung des bedingten Breakpoints anhalten (bzw. direkt nach dem vorherigen Befehl),
aber kann sein, dass er diese Breakpoint-Bedingung doch noch prüft, weil der Debugger grade auf dieser Zeile landet.
Und weil der Breakpoint grade "nicht" zutrifft, dann fehlerhaft ins F9 weitergeht (was dieser Breakpoint normal ja machen würde ... nja, eigentlich ohne Änderung einfach weiter, aber zum Prüfen muß der Debugger ja "unbemerkt" kurz anhalten und dann neu starten, oder nicht).

Ja, würde es auch als Fehler betrachten.
Aber nur diese "Vermutung", warum er es leider nicht macht. (als Hinweis/Vermutung für deine Fehlermeldung, bzw. für weitere Suchen, nach diesem Problem)


Mach mal ein

Delphi-Quellcode:

Beep;

,

Delphi-Quellcode:

Sleep(0);

,

Delphi-Quellcode:

if Tag = 0 then ;

oder sowas als "leeren" Befehl zwischen deine beiden Zeilen.




PS: Warum F8 und nicht F7?
Du hast doch nicht etwas die grauenhaften DebugDCUs in den Projektoptionen aktiv?
Es war echt eine schwachsinnige perverse perfide Idee, diese Option in neuen Projekten standardmäßig zu aktivieren. (und seit Jahrzehnten sooooo unfähig/unwillig zu sein, dass wie zurück zu ändern)

Bei F7 (ohne DebugDCUs) passiert das auch?

[stahli]

Vielen Dank!

Hier mal ein aktuelles Video mit ein paar neuen Infos: https://youtu.be/6TTqxOtXfj0

M.E. ist das ein Delphi-Bug.
So richtig klar ist mir aber nicht, was da falsch läuft...

[himitsu]

Man kann sich bestimmt via OTA in den Debugger hängen?

Wenn ja, dann könnte man sich eventuell anzeigen lassen, wann die Bedinnung des Haltepunktes ausgewertet wird, (entsprechend meiner Vermutung von oben)
und dort via MessageBox oder MessageAPI eine Meldundung ins Ereignis-Fenster der IDE ausgeben lassen.
(OutputDebubString geht innerhalb der IDE natürlich nicht, außer man debuggt die IDE selber)

[stahli]

Jetzt bringen die zwei Dummy-Zeilen bei der realen Arbeit auch nichts mehr.

Ich versuche morgen (weil ich keine VM nutze und morgen sowieso ein komplettes Update mache) mal den Delphi-Patch und wenn das Problem dann noch besteht, mal ein kleines Testprojekt nachzustellen.

[venice2]

Ich habe festgestellt wenn man innerhalb einer Funktion eine andere aufruft wie OutputDebugString dann muß der BreakPoint innerhalb dieser Funktion gesetzt werden.
Ansonsten überspringt der Debugger einfach die nächste Zeile.

Debugg doch mal mit der Unit welche die Funktion OutputDebugString enthält und setze dort den Breakpunkt.
Danach sollte eigentlich die nächste Zeile wo sich der BreakPoint befindet nach OutputDebugString angesprungen werden.

Der Compiler vor allem für 64Bit spinnt mit unter was das debuggen angeht.
Ich habe des öfteren das gleiche Problem wie du gezeigt hast im Video!

Versuch macht klug ;)

PS:
Und ja es ist ein Delphi-Bug.

[Sinspin]

Ich verwende noch RIO. Da kann ich aktuell keine Dlls debuggen. (Keine Haltepunkte)
Ging bis vor zwei, drei Monaten noch problemlos. (In der Zeit kamen keine Updates für RIO, nur der übliche Windows kram).

Jetzt starte ich Delphi zum Debuggen der Dll, es wird mit jedem Start etwas mehr RAM verschleudert.
Irgendwann gibt es dann eine "Speicher voll" Exception in Delphi, überlebt die IDE das, kann ich dann die Dll ordentlich Debuggen und habe funktionierende Haltepunkte.
Das geht meißt nur einmal, danach ist dann ein Neustart der IDE angesagt.

Ich vermute irgend ein Windows Update.
Just seit gestern funktioniert auch einiges an externer Hardware nicht mehr. Die Interfaces haben einfach neue Namen bekommen. Extra arbeit, herrlich.

[stahli]

Ich habe mal ein Testprojekt zusammengeschustert.
Jetzt konnte ich das Problem reproduzieren aber noch nicht näher eingrenzen (könnte mit den Interfaces und/oder Properties zusammenhängen).

Könntet Ihr erst mal testen, ob das Problem bei Euch auch auftritt?

Einfach mit F9 starten bis zum ersten Breakpoint.
Dann mit F8 schrittweise weiter gehen.

Wenn der zweite Breakpoint mit enthaltenen Bedingungen erreicht wird, wird ab dort alles übersprungen.
Wenn der zweite Breakpoint deaktiviert ist, funktioniert alles korrekt.

Wenn NUR der zweite Breakpoint aktiviert ist funktioniert es auch.

[Der schöne Günther]

Ja, mit F8 klappt da irgendwas nicht (10.0 Seattle).
Mit F7 scheint er aber weiterhin zu machen was er sollte, auch wenn beide Haltepunkte aktiviert sind?

Wenn ich Assembler lesen könnte, dann könnte ich bestimmt sagen ob der generierte Code korrekt ist, aber das scheint er auf den ersten Blick nach ja zu sein, oder?

[jaenicke]

Wenn da nicht die Bedingung (Value1 = 3) and (Value2 = 3), die logischerweise nie erfüllbar ist, drin wäre, würde der Haltepunkt auch gehen. Das siehst du sofort in der Liste der Haltepunkte.

Da der Pfad in der .dsk nicht zu meinen Pfaden passt, funktioniert auch das Entfernen mit F5 und das erneute Setzen nicht. Das ist ein Bug, dass dann die Bedingung dennoch greift obwohl es quasi ein zusätzlicher Haltepunkt in der Zeile ist.

[stahli]

Danke Euch.

@jaenicke

Deine Erklärung verstehe ich nicht wirklich.
Kannst Du (oder jemand anders mit gutem Englisch) das bei Emba evtl. mal als Bug melden?

Ich könnte es auch melden, wäre aber vermutlich weniger gut verständlich.

[stahli]

Ich habe mal versucht, einen Eintrag zu erstellen: https://quality.embarcadero.com/browse/RSP-34094

[jaenicke]

Ich hatte leider keine Zeit, aber ich habe dazu nun noch etwas ergänzt.

[stahli]

Danke. :thumb:

[stahli]

@jaenicke

Kannst Du nachvollziehen, was Emba da gemacht hat?
Angeblich wäre der Bug aktuell wohl nicht mehr nachvollziehbar - oder?

In D11 habe ich das Problem aber noch unverändert. :-(

[Uwe Raabe]

Ich kann das auch unter Delphi 11 noch nachvollziehen. Du solltest über Dispute Resolution den Bug wieder öffnen.

[stahli]

aus dem Quality-Thread:

Zitat:

Andre Stahl added a comment - Just now
The problem still exists in Delphi 11.1 :-(

[stahli]

Antwort auf https://www.delphipraxis.net/1503705-post89.html :

- alle *.dsk und *.~dsk gelöscht
- beide Breakpoints waren nach Öffnung des Projektes entfernt
- beide Breakpoints neu definiert
- Problem besteht weiter

[stahli]

In 11.2 existiert das Problem weiterhin.
Ich habe das nochmal im QP eingetragen - aber wenig Hoffnung. Debugging ist natürlich auch nicht ganz so wichtig.

[jaenicke]

Letztlich bleibt erst einmal nur, dass du die Bedingungen weglässt. Ein Workaround ist ja, dass du die Bedingung per if..then prüfst. Dann setzt du den Haltepunkt einfach auf eine Zeile innerhalb des if..then und schon landest du nur im Haltepunkt, wenn die Bedingung erfüllt ist.

Trotzdem frage ich mich wieso das Problem bei Neudefinition der Haltepunkte entsteht. Ich kann das nur mit den schon definierten Haltepunkten nachvollziehen, kann das Problem aber nicht von Anfang an reproduzieren.

[freimatz]

Zitat:

Zitat von stahli (Beitrag 1512020)

Debugging ist natürlich auch nicht ganz so wichtig.

wuzz? :shock::roll:
Ich habe heute Stand 08:10 Delphi schon vier mal neu gestartet wegen diversen AVs und Internal Errors. Das ist noch vergleichbar harmlos, ich kann immerhin noch entwickeln. Aber wenn ich mal nicht mehr Debuggen kann weil das Programm nicht an Breakpoints anhält oder das Watch keine Werte anzeigt, dann ist es aus.

[jaenicke]

Das habe ich ironisch verstanden. :wink:

[stahli]

Ja klar war das ironisch gemeint. Als wenn sich bei einem Auto mit Frontantrieb die Hinterräder nicht drehen, aber man ja einfach Ski drunter klemmnen kann.

Ich habe jetzt das Neuanlegen der Breakpoints nicht noch einmal versucht, da es beim letzten Mal ja auch nichts brachte.
Emba hat ja offenbar das Problem vor 15 Monaten auch als solches selbst bestätigt.
Dann sollte es auch mal irgendwann geklärt werden.

[jaenicke]

Zitat:

Zitat von stahli (Beitrag 1512069)

Ich habe jetzt das Neuanlegen der Breakpoints nicht noch einmal versucht, da es beim letzten Mal ja auch nichts brachte.

Die Frage ist ja vor allem, ob danach die Pfade auch wieder falsch sind (und wenn ja, wie das sein kann).

Ich kann mir das nur so erklären, dass das Propblem ursprünglich passiert ist, weil du die betreffenden Dateien doppelt auf dem PC hattest und die falsche Unit per Drag-And-Drop in Delphi hinein geöffnet hast. Wenn man dann dort die Haltepunkte setzt, entsteht tatsächlich das Problem.

[stahli]

Ich schaue mir das heute Abend nochmal an.

M.E. wird der fragliche Haltepunkt direkt berücksichtigt, wenn ich die Bedingung lösche.
Das heißt, er muss ja an der richtigten Stelle verknüpft sein.

Mal sehen, ob ich heute Abend etwas finde. So oder so müsste die IDE aber doch nun mal inzwischen wenigstens erkennen, dass da etwas nicht stimmt.

EDIT: Der Haltepunkt wird ja mit F7 oder F8 auch nicht einfach ignoriert sondern die Anwendung wird von der Stelle aus direkt bis zum nächsten gültigen Haltepunkt übersprungen.

[stahli]

Ich kam erst jetzt dazu, aber ohne neue Erkenntnisse.

Beide Haltepunkte entfernt und neu gesetzt ohne Bedingungen.
Funktioniert wie erwartet. F9 geht bis zum ersten Haltepunkt, F8 geht dann zeilenweise und über den zweiten Haltepunkt hinweg (ganz normal).

Dann neuer Versuch mit Bedingung "(Value1 = 3) and (Value2 = 3)" für den zweiten Haltepunkt und Neustart.
F9 geht wieder bis zum ersten Haltepunkt. Schrittweise F8 wird ab zweitem Haltepunkt wie F9 ausgeführt. :cry:

[stahli]

Mit D11.3 besteht das Problem unverändert.

[stahli]

Mit Delphi 12.2 keine Änderung. :-(

Aber Delphi hat ja jetzt KI. Die wird das Problem bald lösen. Ich freue mich drauf.


Delphi ist frisch installiert und nur Codesite Express zusätzlich.
Habe die Breakpoints extra gelöscht und neu angelegt.

[stahli]

Ich habe mal einen neuen Fall in dem neuen Portal (scheint ja ein neues zu geben) angelegt:

https://embt.atlassian.net/servicede...tal/1/RSS-1858

Offenbar war der alte wohl verloren gegangen (so würde ich das zumindest mal einschätzen). :-(

[dummzeuch]

Zitat:

Zitat von stahli (Beitrag 1541376)

Ich habe mal einen neuen Fall in dem neuen Portal (scheint ja ein neues zu geben) angelegt:

https://embt.atlassian.net/servicede...tal/1/RSS-1858

Offenbar war der alte wohl verloren gegangen (so würde ich das zumindest mal einschätzen). :-(

Den Bug Report kannst nur Du sehen. Du musst ganz unten links "Share with Embarcadero Customers" auswählen, damit wir ihn auch sehen können.

[stahli]

Danke, erledigt.
(da muss man erst mal drauf kommen)

[Uwe Raabe]

Zitat:

Zitat von stahli (Beitrag 1541379)

(da muss man erst mal drauf kommen)

Das ist aber die Voreinstellung beim Anlegen eines neuen Bugs, die man dann bewusst ändern müsste um es zu deaktivieren.

[stahli]

Ich habe bewusst da nichts umgestellt (wenn, dann versehentlich).

[TiGü]

Zitat:

Zitat von stahli (Beitrag 1541376)

Ich habe mal einen neuen Fall in dem neuen Portal (scheint ja ein neues zu geben) angelegt:

https://embt.atlassian.net/servicede...tal/1/RSS-1858

Offenbar war der alte wohl verloren gegangen (so würde ich das zumindest mal einschätzen). :-(

Wenn du ein sauberes Projekt nimmst (nur PAS-, DPROJ-, DPR-, DFM-Dateien), also den ganzen Müll wie DSK-Dateien usw. löschst, kannst du sauber Debuggen und landest auch per F8 im zweiten Breakpoint.

Siehe Anhang, viel Spaß damit.

[stahli]

@TiGü

Danke, aber ich kann das hier nicht nachstellen.

Ich habe
1.) alle Dateien ausser Deiner genannten entfernt und
2.) genau nur Deine Dateien verwendet

und jeweils die Breakpoints wie vorgegeben angelegt, wobei das Problem direkt wieder auftritt.


Im Quality-Portal ist der Fall jetzt als "offen" eingestuft. Mal sehen...