Argument außerhalb des gültigen Bereichs (for-Schleife zählt ins Minus)

[SneakyBagels]

Zitat:

Wer weiß, was da noch im Argen liegt.

Meine Schuld kanns ja nicht sein denn wenn dem so wäre, dann würde ja auch der 32 Bit Modus alles verhnunzen.

Und noch eine Erkenntnis.
Wenn ich die Schleifenvariale j verwende statt i (wie es just oben über der for-Schleife passiert denn da ist noch eine andere), dann kommt der Fehler auch nicht.

[Luckie]

Aber bevor das hier wieder eskaliert. Wir meinen es nur gut. Wir wollen deinen Code nicht schlecht reden oder dich fertig machen. Sehe es als Ratschlag und konstruktive Kritik. Wenn du damit leben kannst, OK. Aber sei dir bewusst, dass da im Code eventuell eine Zeitbombe tickt.

Zitat:

Meine Schuld kanns ja nicht sein denn wenn dem so wäre, dann würde ja auch der 32 Bit Modus alles verhnunzen.

Öhm. Kleines Gedankenspiel. Nehmen wir an es gäbe keinen 32-Bit Compiler, dann könntest du diese Aussage nicht mehr treffen, da du keine Kenntnis hast, wie ein 32-Bit Compiler deinen Code übersetzen würde. Wahrscheinlich ist es einfach nur Glück, dass es unter 32- Bit so übersetzt wird, wie du es wünschst.

[SneakyBagels]

Nur wie kann es sein, dass mir eine Schleifenvariable i scheinbar verhext wird von einem Code der nie angesprungen wird?
Ich bin gerade noch einmal alles grob durchgegangen und es passiert nur unter 64 Bit.

[Luckie]

Ja. Hilft wohl nichts. Häng die Unit mal an. Oder zeig die Prozedur in der der Fehler auftritt. Was mir einfällt: Wie sieht es mit den (Interger)Datentypen aus?

[nahpets]

Gibt es zufällig eine globale Variabel gleichen Namens?

Mach bitte aus j nochmal i, lasse aber die deklaration von i weg.

Eigentlich wäre zu erwarten, dass der Compiler dann die fehlende Deklaration bemängelt.

Sollte dem nicht so sein, wäre das mal eine Überprüfung wert.

Naja, dass der 32 Bit-Compiler richtig arbeitet und der 64er falsch, kann Zufall sein, könnte in anderen Situationen auch andersherum sein.
Die Wahrscheinlichkeit, dass beide oder einer von ihnen absolut fehlerfrei arbeitet, dürfte gegen Null tendieren.

[SneakyBagels]

Zitat:

Naja, dass der 32 Bit-Compiler richtig arbeitet und der 64er falsch, kann Zufall sein, könnte in anderen Situationen auch andersherum sein.

Pass auf was sagst du dazu.

Folgender Code steht genau so an der Stelle ab wo i plötzlich bis zu -1 geht

Delphi-Quellcode:

             for i := cList.Count - 1 downto 0 do
              ShowMessage(IntToStr(i));
             ShowMessage('End1');

             for i := cList.Count - 1 downto 0 do
              ShowMessage(IntToStr(i));
             ShowMessage('End2');

Zwischen den beiden Schleifen steht bis auf die ShowMessage nichts.

Unter XE8 64 Bit absolut keine Probleme. Generell gibts da keine Probleme. Tokyo spinnt hier rum und macht mir die Zicken mit dem -1.

Zitat:

Oder zeig die Prozedur in der der Fehler auftritt

Hatte ich auf Seite 2

Zitat:

Zitat von SneakyBagels (Beitrag 1371197)

Zitat:

Zitat von Uwe Raabe (Beitrag 1371196)

Zitat:

Zitat von SneakyBagels (Beitrag 1371193)

Sagen wir mal so: ein großer Thread, er funktioniert absolut perfekt

Tut er nicht!

Rechnen wir diesen Schluckauf mal raus, dann tut er es :thumb:

Ich konnte das Suchgebiet eingrenzen. Ich rufe an einer Stelle vorher eine Funktion auf welche 5 Parameter akzeptiert. Drei davon sind

Delphi-Quellcode:

TFile.GetCreationTime(s), TFile.GetLastAccessTime(s), TFile.GetLastWriteTime(s)

s beinhaltet einen Pfad zu einer Datei. Der Code wird nicht immer ausgeführt. Nur sehr sehr selten und hier in meinem Fall sogar gar nicht.
Wenn ich 1x TFile.... weglasse und durch Now ersetze, funktioniert meine Schleife auch korrekt.

Hat der Compiler hier Schluckauf?

Ist jetzt aber ehrlich gesagt total unwichtig. Ich habe die Stelle gefunden die den Fehler auslöst und schuld dran sind die drei TFile.

[jaenicke]

Zitat:

Zitat von SneakyBagels (Beitrag 1371205)

Ich habe die Stelle gefunden die den Fehler auslöst und schuld dran sind die drei TFile.

Wenn es wirklich so ist, dann dürftest du ein Speicherproblem haben. Sprich irgendwo Speicher überschreiben oder ähnliches. Denn anders wäre das kaum zu erklären...

Ob der Compiler hier etwas falsch macht, lässt sich leicht klären, indem du den Assemblercode der Schleife postest. Dafür brauchst du nur an der Stelle einen Haltepunkt setzen und Strg + Alt + C drücken. Dann siehst du den Assemblercode und dazu jeweils den Pascal-Code. Den kannst du dann einfach von Anfang bis Ende der Schleife kopieren und posten.

[SneakyBagels]

Wie genau komme ich denn an den Assemblercode? Breakpont ja gut aber Assembercode? Falls du das hier meinst

Delphi-Quellcode:

cThreadC.pas.1270: ShowMessage(IntToStr(i));
0000000000C0D1F8 488B8560090000   mov rax,[rbp+$00000960]
0000000000C0D1FF 8B4020           mov eax,[rax+$20]
0000000000C0D202 89859C000000     mov [rbp+$0000009c],eax
0000000000C0D208 488D8DB8040000   lea rcx,[rbp+$000004b8]
0000000000C0D20F 8B959C000000     mov edx,[rbp+$0000009c]
0000000000C0D215 E8469A82FF       call IntToStr
0000000000C0D21A 488B8DB8040000   mov rcx,[rbp+$000004b8]
0000000000C0D221 E88A83A4FF       call ShowMessage
uThreadC.pas.2523: end;                                    // Das hier ist das end vom Execute-Block
0000000000C0D226 488B8560090000   mov rax,[rbp+$00000960]
0000000000C0D22D 488D4020         lea rax,[rax+$20]
0000000000C0D231 832801           sub dword ptr [rax],$01
uThreadC.pas.1269: for i := cList.Count - 1 downto 0 do
0000000000C0D234 8B859C000000     mov eax,[rbp+$0000009c]
0000000000C0D23A 85C0             test eax,eax
0000000000C0D23C 7DBA             jnl TThreadC.Execute + $1498
uThreadC.pas.1271: ShowMessage('END');
0000000000C0D23E 488D0D77660000   lea rcx,[rel $00006677]
0000000000C0D245 E86683A4FF       call ShowMessage

Wie gesagt. Nur diese eine einzige Zeile mit dem 3x TFile kommentieren und das Problem ist weg nur seltsam ist es schon. Bzw. 1x von den 3 TFile rausnehmen reicht auch schon.

Gerade früh noch schnell einen Test gemacht. Lasse ich TFile... komplett weg und füge stattdessen das hier ein

Delphi-Quellcode:

function FileTimeToDateTime(FileTime: TFileTime): TDateTime;
var
 ModifiedTime: TFileTime;
 SystemTime: TSystemTime;
begin
 Result := 0;
 if (FileTime.dwLowDateTime = 0) and (FileTime.dwHighDateTime = 0) then
  Exit;
 try
  FileTimeToLocalFileTime(FileTime, ModifiedTime);
  FileTimeToSystemTime(ModifiedTime, SystemTime);
  Result := SystemTimeToDateTime(SystemTime);
 except
  // Prevent a black whole
 end;

GetFileAttributesEx(PChar(s), GetFileExInfoStandard, @fileDate);

FileTimeToDateTime(fileDate.ftCreationTime),
FileTimeToDateTime(fileDate.ftLastAccessTime),
FileTimeToDateTime(fileDate.ftLastWriteTime),

dann ist der Fehler auch weg. Es scheint also zu 100% (?) etwas mit dem TFile-Record zu tun zu haben.

[mensch72]

Delphi-Quellcode:

for i := cList.Count - 1 downto 0 do
    ShowMessage(IntToStr(i));
ShowMessage('End1');

for i := cList.Count - 1 downto 0 do
    ShowMessage(IntToStr(i));
ShowMessage('End2');

Fragen:
- Ist das in einer "globalen" Funktion, in einer Objectfunktion oder in einer lokalen Funktion?
- Wie und wo und als was ist "i" deglariert ? (global, in Klasse, lokal / Integer,Cardinal,Int64,...)
- Tokio mit oder ohne Hotfix1

[jaenicke]

Die Schleife fängt schon etwas früher an (die steht doppelt drin, einmal am Anfang der Schleife einmal am Ende), aber zumindest die Abbruchbedingung der Schleife sieht vollkommen korrekt aus.

Die Speicheradresse für die Variable sieht etwas komisch aus, aber ich kenne hauptsächlich 32 Bit Assembler, den Delphi generiert. Das kann also völlig normal sein.

Der angezeigte Assemblercode ist allerdings der, der kompiliert wurde, nicht der, der im Speicher liegt.

Das und die Tatsache, dass eine Änderung an anderer Stelle das Problem löst, spricht tatsächlich für ein Speicherproblem.

Du kannst einmal schauen ob FastMM etwas findet.