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

[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 von SneakyBagels:

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 von SneakyBagels:

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 von SneakyBagels:

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.

[SneakyBagels]

Ich denke ich bin einen Schritt weiter und ich konnte meine Suche auf eine einzige Unit eingrenzen.

Ich habe diese Unit, es ist ein Thread, nun flott in eine normale Class umgeschrieben. Sämtliche Queue und Synchronize sind raus.
Was passiert? Das Problem ist weg. Nur ist das auch keine Lösung.

Problem gelöst!
Es gab genau ein Synchronize in Execute(), so ziemlich am Anfang, wo ich die Variable i von Execute() verwendet habe.
Das sollte doch eigentlich gar nicht möglich sein, da man in Synchronize doch immer eine lokale Schleifenvariable braucht.