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

[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 :stupid: Deine Operationen mit

Delphi-Quellcode:

TFile

sind hier auch nicht umbedingt der Auslöser - können natürlich aber.

Nur zur Sicherheit:
Als was hast du

Delphi-Quellcode:

fileDate

deklariert, welches du an die GetFileAttributesEx API übergibst?

[SneakyBagels]

Zitat:

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 hier wieder die Fragen...
1: warum ist der Fehler komplett weg sobald ich TFile 2x verwende statt 3x (oder halt gar nicht)
2: warum nur bei 64 Bit
3: und warum nicht bei XE8

fileDate ist als TWin32FileAttributeData deklariert.

Woran erkennt man einen BufferOverflow denn? Was muss man da falsch machen um den zu erzeugen.

[Zacherl]

Zitat:

Zitat von SneakyBagels (Beitrag 1371247)

Zitat:

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 hier wieder die Fragen...
1: warum ist der Fehler komplett weg sobald ich TFile 2x verwende statt 3x (oder halt gar nicht)
2: warum nur bei 64 Bit
3: und warum nicht bei XE8

Sobald IRGENDWO ein BufferOverflow stattfindet, ist der restliche Programmablauf komplett undeterministisch (zumindest erscheint es unserer beschränkten Wahrnehmung so). Das mit Logik erklären zu wollen, ist grundsätzlich zum Scheitern verurteilt.
1. Dadurch verschieben sich die Variablen auf dem Stack / der Stack wird kleiner / anderer Code wird generiert, wodurch dann letztendlich vielleicht eine andere Variable überschrieben wird und nicht dein Schleifen-Zähler oder

Delphi-Quellcode:

List.Count

. Kann man nur spekulieren.
2. Auch hier wird anderer Code generiert / bestimmte Datentypen (Pointer z.b.) sind auf einmal 8-Byte statt 4-Byte groß, wodurch sich die Position der lokalen Variablen auf dem Stack ebenfalls wieder verändert.
3. Kann man wieder nur spekulieren. Vermutlich wird der Code hier auf andere Weise generiert / optimiert, weshalb sich erneut die Position der Variablen auf dem Stack ändern könnte.

Zitat:

Zitat von SneakyBagels (Beitrag 1371247)

fileDate ist als TWin32FileAttributeData deklariert.

Gut, das scheint korrekt zu sein (sofern du den Typ aus der Winapi.Windows.pas verwendest).

Zitat:

Zitat von SneakyBagels (Beitrag 1371247)

Woran erkennt man einen BufferOverflow denn? Was muss man da falsch machen um den zu erzeugen.

BufferOverflows sind fiese Fehler, die man nur schwer erkennen kann. Oft treten sie bei Verwendung von Arrays (Schreibzugriffe nach dem letzten validen Index) oder bei der Verwendung von untypisierten Pointern (wie z.b. im Falle von GetFileAttributesEx) auf. Wäre z.b. das

Delphi-Quellcode:

TWin32FileAttributeData

angenommen mal 4-Byte zu klein und auf dem Stack liegt zufälligerweise eine lokale Integer-Variable direkt hinter dem Struct, dann würde die API fehlerhafterweise den Wert der dahinterliegenden Variable mit "Irgendwas" überschreiben.

[SneakyBagels]

Zitat:

Oft treten sie bei Verwendung von Arrays (Schreibzugriffe nach dem letzten validen Index)

Solche Fehler zu vermeiden da achte ich peinlichst genau drauf.

Nur stellt sich mir noch immer die Frage, warum XE8 das Problem nicht hat Tokyo ohne HF aber schon. Und warum nur 64 Bit. Dann müsste das 32er Kompilat ja auch Probleme haben wenn es ein Codefehler wäre.
Wenn es tatsächlich ein BufferOverflow irgendwo wäre (falscher Index Array ...), dann müsste ich doch schon vorher wenigstens Zugriffsverletzungen oder ähnliche Fehler sehen.

Wie bereits erwähnt besteht der Fehler erst seit dem Umstieg auf Tokyo.

FastMM4 zeigt keinerlei Auffälligkeiten. Memory Leaks gibt es auch keine.

[Zacherl]

Zitat:

Zitat von SneakyBagels (Beitrag 1371252)

Nur stellt sich mir noch immer die Frage, warum XE8 das Problem nicht hat Tokyo ohne HF aber schon. Und warum nur 64 Bit. Dann müsste das 32er Kompilat ja auch Probleme haben wenn es ein Codefehler wäre.

Ich kann mich an dieser Stelle nur nochmal selbst zitieren:

Zitat:

Sobald IRGENDWO ein BufferOverflow stattfindet, ist der restliche Programmablauf komplett undeterministisch (zumindest erscheint es unserer beschränkten Wahrnehmung so). Das mit Logik erklären zu wollen, ist grundsätzlich zum Scheitern verurteilt.

XE8 und Tokyo haben unterschiedliche Compilerversionen und damit auch unterschiedliche Codegenerierung und Codeoptimierung. Ebenso unterscheidet sich die Codegenerierung zwischen 64 und 32 Bit (unter anderem in der von mir erwähnten Form der unterschiedlichen Größe bestimmter Datentypen).

Zitat:

Zitat von SneakyBagels (Beitrag 1371252)

Dann müsste das 32er Kompilat ja auch Probleme haben wenn es ein Codefehler wäre.

Die Annahme ist leider falsch. Unter 32-Bit wird sehr wahrscheinlich einfach eine Speicherstelle überschrieben, die zu diesem Zeitpunkt schon irrelevant oder sogar komplett unbenutzt ist.

Zitat:

Zitat von SneakyBagels (Beitrag 1371252)

Wenn es tatsächlich ein BufferOverflow irgendwo wäre (falscher Index Array ...), dann müsste ich doch schon vorher wenigstens Zugriffsverletzungen oder ähnliche Fehler sehen.

Die Annahme ist ebenfalls falsch. Es kommt erst dann zu Fehlern, wenn dein Code die überschriebenen Speicherbereiche verwendet und an der dortigen Stelle bestimmte Daten erwartet, die dann natürlich nicht mehr stimmen. Das KANN eine Zugriffsverletzung sein (sofern z.b. nochmal eine Dereferenzierung stattfindet), kann aber auch genausogut andere Seiteneffekte haben. Kaputte Schleifenzähler sind hier sogar sehr häufig.

[SneakyBagels]

Zitat:

XE8 und Tokyo haben unterschiedliche Compilerversionen und damit auch unterschiedliche Codegenerierung und Codeoptimierung.

Jetzt bin ich hin und her gerissen und weiß nicht, ob ich jetzt einen BufferOverflow suchen soll oder nicht.
Ich bin mir aber 100% sicher, dass ich selber keine eingebaut habe.

[Zacherl]

Also es gibt auch Tools, um BufferOverflows zu erkennen. Leider habe ich damit nur Erfahrung bei Visual Studio und kann dir für Delphi hier nicht großartig weiterhelfen.