XE2 Update3 Debugger Problem

[wurzelzwerg]

Moin.
Hab mit das Update3 installiert. Jetzt springt der 64bit-Debugger nicht mehr zu Sourcezeilen mit Laufzeitfehlern.
Bei 32bit ist es auch nicht die richtige Zeile sondern irgendwo danach(bei FMX, mit VCL geht auch das nicht).
Ist das ein Fehler oder ne verbogene Einstellung?

[Bernhard Geyer]

Hast du schon mal einen kompletten rebuild deines Projektes durchgeführt?

[wurzelzwerg]

Ja. Das passiert auch in einem neuen Projekt. Nur ein Button mit i:= StrToInt('aaa');

[Insider2004]

Probier mal Andis IDE-Fix-Pack. Gehts dann?

[wurzelzwerg]

IDE-Fix-Pack hilft auch nicht.

Hast du das Problem nicht?

[daywalker9]

Mit deinem Beispiel klappt das wunderbar mit dem Debugger.

Hast Du evtl die Exceptions ignoriert unter Tools, Debugger Optionen?

[wurzelzwerg]

Zitat:

Zitat von daywalker9 (Beitrag 1143007)

Hast Du evtl die Exceptions ignoriert unter Tools, Debugger Optionen?

Nee nee, das wäre zu einfach :-D Ich bekomme den Fehler ja angezeigt.
Hab noch mal alles runtergeschmissen, bis Update2 funktioniert der Kram.
Mit Update3 gehts nicht. :x

[wurzelzwerg]

So, ich habe XE2 Udpate3 noch mal auf einem neuen Windows installiert(XP und Win7 probiert, Ergebnis identisch).
Dann neues FMX-HD-Anwendung(32bit), Form mit Button:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  i: integer;
begin
  i:= StrToInt('xxx');
  if i > 0 then
    Caption:= 'blah';
end;

Debugger springt nicht zum Fehler sondern zur letzten Zeile in der Projektdatei, also zum end. nach Application.Run.
Wieso funktioniert das bei dir?

[daywalker9]

Achso, eine FMX Anwendung. Habs gerade ausprobiert und bei mir ist es auch so, das er in Application.Run springt.

//Edit:

Nur bei StrToInt klappst nicht, wenn ich nun z.B.:

Delphi-Quellcode:

 procedure TForm15.Button1Click(Sender: TObject);
begin
  SetName(PString(nil)^);
end;

hält der Debugger auch an der Funktion an

[wurzelzwerg]

Bei Update2 hält er aber beim Fehler an, also eine Zeile nach StrToInt.
Das ist ja nur mein Test. Gemerkt hab ich das in einem Projekt wo die Bereichsprüfung zugeschlagen hat(FMX, 64bit).
Da landet man nirgends im Gegensatz zu Update2. Bei 32bit kommts irgenwie auf den Fehler an.
Also so was(64bit):

Delphi-Quellcode:

procedure TForm15.Button1Click(Sender: TObject);
var i: integer; arr: array[0..3] of integer;
begin
  i:= 8;
  arr[i]:= 0;
end;

[USchuster]

Du solltest in den Projektoptionen die Option "Mit Debug-DCUs" aktivieren (Delphi-Compiler | Compilieren -> Debuggen). Nur wenn diese Option aktiviert ist, dann erhält man einen vernüftigen Callstack, der Debugger springt zur Stelle wo der Fehler auftritt und über den Callstack findest Du den Fehler in Deinem Code. Damit funktioniert "Anhalten" beim genannten FMX StrToInt Fall. In einer Delphi 7 VCL Anwendung mit diesem Code ist das gleiche Verhalten zu beobachten wie in der Win32 FMX Variante.

[daywalker9]

Debug-DCUs ja, für Dinge die man schwer lokalisieren kann. Aber beim alltäglichen Debugger ist das eher hinderlich, wenn man immer in _UStr* Funktionen kommt etc..

[wurzelzwerg]

Debug-DCUs helfen auch nichts, damit lande ich im RTL error handler im SysUtils(array Fall), bei StrToInt im Nirgendwo.
Bei Update2 funktionierte der Kram ja noch.
Einen vern. Call Stack habe ich auch so, als einzige Möglichkeit überhaupt in die Nähe des Fehlers zu kommen.
Der unterscheidet sich auch nicht zu Update2.
Ich halt's für'n Bug und hab das bei QC eingetragen.