Debug-Bug ?

[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.