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

[jaenicke]

Zitat von SneakyBagels:

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

[SneakyBagels]

Antworten

1. diese beiden Schleifen stecken mitten im Execute-Block eines Threads
2. i ist lokal im Execute-Block deklariert, ein globales i gibt es nicht
3. Tokyo noch ohne Hotfix da mir die Zeit fehlt eine etwaige Fehlinstallation zu reparieren

Ohne TFile ist der Fehler weg. XE8 hat mit den 3 TFile's keine Probleme. Das 32 Bit-Kompilat auch nicht. Nur Tokyo mit 64 Bit meckert.

Zitat:

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

Liegt das dann an mir oder am Compiler/an Delphi? Denn wie gesagt gibt es unter XE8 keinerlei Probleme weder 32 och 64 Bit.
Mit Speicherproblem meinst du aber keine defekte Hardware?

[jaenicke]

Nein, ich meine überschriebenen Speicher z.B., aber das heißt nicht, dass das an deinem eigenen Quelltext liegen muss. Es kann natürlich auch ein Fehler in der neuen Delphiversion sein. Die Wahrscheinlichkeit ist zwar nicht besonders hoch, aber möglich ist alles.

Ich schaue mir die Implementierungen einmal an.

[SneakyBagels]

Ich habe gerade auch flott mal drüber geguckt. Es gibt zwar von XE8 zu Tokyo einige Änderungen (45 laut Anzeige) aber das meiste betrifft nur Linux.

[Zacherl]

Definitiv ein Buffer-Overflow an irgendeiner anderen Stelle, der das Problem letztendlich verursacht. Viel Spaß beim Suchen Deine Operationen mit TFile sind hier auch nicht umbedingt der Auslöser - können natürlich aber.

Nur zur Sicherheit:
Als was hast du fileDate deklariert, welches du an die GetFileAttributesEx API übergibst?

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