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 Beep; , Sleep(0); , 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.