StringReplace verursacht AV

[Zacherl]

Delphi-Quellcode:

for IntI := 0 to 3 do

= 4

Klassischer Buffer-Overflow.

SetLength etc. erwartet die Größe des Array und nicht den höchsten Index. Also entweder SetLength(3) und die Schleife von 0..2 oder SetLength(4) und die Schleife von 0..3.

[EWeiss]

Zitat:

Zitat von Zacherl (Beitrag 1350335)

Delphi-Quellcode:

for IntI := 0 to 3 do

= 4

Klassischer Buffer-Overflow.

SetLength etc. erwartet die Größe des Array und nicht den höchsten Index. Also entweder SetLength(3) und die Schleife von 0..2 oder SetLength(4) und die Schleife von 0..3.

Argg.. Ja du hast recht.
Erklärt aber nicht warum der Fehler in einer anderen Unit bei StringReplace auftritt was eigentlich mit dem Problem nichts zu tun hat.
Und das direkt zweimal einmal in der Form und einmal in einer anderen Unit also überall da wo StringReplace Verwendung findet.

Die Form ist kein Teil meiner DLL.. Sehr komisch oder?

gruss

[himitsu]

Zitat:

Zitat von EWeiss (Beitrag 1350338)

Die Form ist kein Teil meiner DLL.. Sehr komisch oder?

Weil die ganze Anwendung EINEN gemeinsamen (vituellen) Arbeitsspeicher besitzt und du demnach "irgendwas" in dem Speicher überschreiben kannst, auch was nicht zu deiner DLL gehört.

Damals, als noch ALLE Programme und Windows sich den gesamten Arbeitsspeicher teilten und es nicht getrennt war, da hättest du statt Deinem auch ein fremdes Programm oder gleich das Windows zerschrotten können.


PS: Bei solchen Fehlern kann man sich in den Projektoptionen auch mal die Überlauf- und Bereichsprüfungen aktivieren.

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1350346)

Zitat:

Zitat von EWeiss (Beitrag 1350338)

Die Form ist kein Teil meiner DLL.. Sehr komisch oder?

Weil die ganze Anwendung EINEN gemeinsamen (vituellen) Arbeitsspeicher besitzt und du demnach "irgendwas" in dem Speicher überschreiben kannst, auch was nicht zu deiner DLL gehört.

Damals, als noch ALLE Programme und Windows sich den gesamten Arbeitsspeicher teilten und es nicht getrennt war, da hättest du statt Deinem auch ein fremdes Programm oder gleich das Windows zerschrotten können.


PS: Bei solchen Fehlern kann man sich in den Projektoptionen auch mal die Überlauf- und Bereichsprüfungen aktivieren.

Jup hast recht ;)
Bei StripHotkey trat das Problem aber nicht auf. Warum also bei StringReplace.. LOL

Wie gesagt schon seltsam.

gruss

[Fritzew]

Code:

Wie gesagt schon seltsam.

Nein ist nicht seltsam. Du schreibst in Speicher herum der Dir nicht gehört.
Da kann alles passieren.

[EWeiss]

Zitat:

Zitat von Fritzew (Beitrag 1350366)

Code:

Wie gesagt schon seltsam.

Nein ist nicht seltsam. Du schreibst in Speicher herum der Dir nicht gehört.
Da kann alles passieren.

Erklärt aber immer noch nicht warum es ausgerechnet nur bei StringReplace passiert.

gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1350367)

Zitat:

Zitat von Fritzew (Beitrag 1350366)

Code:

Wie gesagt schon seltsam.

Nein ist nicht seltsam. Du schreibst in Speicher herum der Dir nicht gehört.
Da kann alles passieren.

Erklärt aber immer noch nicht warum es ausgerechnet nur bei StringReplace passiert.

Das ist auch garantiert nicht der Fall. Ob sowas zum Crash führt oder nicht, hängt von tausenden Faktoren ab. Mit der StripHotkey Funktion hast du einfach nur Glück gehabt.

[himitsu]

Es hätte auch schon in der FOR-Schleife knallen können.
Wenn der zu überschreibende Speicherbereich nicht reserviert ist, oder etwas überschrieben wird, was bereits in der Schleife verwendet wird.

Und ob es später knallt oder nicht, das hängt davon ab was überschrieben wird.

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1350371)

Es hätte auch schon in der FOR-Schleife knallen können.
Wenn der zu überschreibende Speicherbereich nicht reserviert ist, oder etwas überschrieben wird, was bereits in der Schleife verwendet wird.

Und ob es später knallt oder nicht, das hängt davon ab was überschrieben wird.

Das hätte ich verstanden da hier ja auch der Fehler produziert wurde.
Aber der andere Fall bleibt ein Rätzel.

Denn nach dem deaktivieren von StringReplace trat kein Fehler mehr auf.
Zu spekulieren es hätte auch woanders auftreten können ist eine Vermutung wie gesagt nach dem deaktivieren kam kein Fehler mehr.
Er hätte also dann an anderer stelle auftreten müssen wenn man der Behauptung nachgehen würde "Es hätte auch schon"

Zitat:

Und ob es später knallt oder nicht, das hängt davon ab was überschrieben wird.

Und das tut es eben nicht.
Immer nur an der gleichen stelle in Verbindung mit StringReplace.
Überall da wo es Verwendung findet.

Zitat:

Das ist auch garantiert nicht der Fall.

Aber 100% 'tig ;)
Andernfalls erkläre mir mal warum es dann nirgends anders kracht nachdem ich diese Zeile/n deaktiviert habe.

gruss

[Fritzew]

Du willst es nicht verstehen oder?
Was da gerade im Speicher steht den Du überschreibst ist "Zufall". Zufall aus Deiner Sicht, für den Speichermanager
hat das alles Seine Richtigkeit. In Deiner Konstellation passiert es beim Stringreplace. Wenn Du aber sonst noch was änderst im Code kann der aktuelle Speicher schon wieder ganz anders aussehen.
Dr Fehler ist 100% Deiner und sonst nichts.