String-Verlängerung => Delphi-Bug?

[sgmeiner]

Hallo zusammen.

Ich bin auf ein Verhalten gestoßen, das ich mir nicht mehr erklären kann und würde gern mal eure Meinungen dazu hören:

Ich habe einige DB-Operationen (ZEOS) in einer DLL gekapselt. Beim ersten Aufruf einer bestimmten Funktion geht alles glatt. Das Problem (die Access Violation) tritt auf, wenn ich die Methode das zweite mal aufrufe. Durch Debuggen der ZEOS-Komponenten bin ich auf die Zeile gestoßen die den Fehler verursacht - was mir aber auch nicht wirklich hilft:
Result.Value := Result.Value + ReadChar; Result ist ein Record, Value ist vom Typ String, ReadChar vom Typ Char. Ich verstehe nicht, dass da eine AV fliegt. Nachdem ich ein wenig im Auswerten-Dialog vom BDS rumgespielt hab, hab ich gemerkt, dass ich den Wert von Result.Value erst mal gar nicht ändern kann. Ich habs versucht, neuen Wert eingegeben, aber die Variable hat scheinbar nur einen leeren String mitgekriegt. Erst beim zweiten Ändern kam der Wert in der Variablen an. Unter diesen Umständen läuft das Programm allerdings anschließend fehlerfrei durch

Meine Vermutung geht in die Richtung, dass der Compiler (BDS2006 + Update 2) hier Probleme hat Speicher für den String zu allokieren... Was meint ihr dazu? Bin momentan absolut ratlos

Danke schon mal für eure Antworten

[Bernhard Geyer]

Strings und DLL? Übergiebst Du diesen Record von der DLL in die Exe bzw. umgekehrt?

[fwsp]

Hast du in der dll die delphi compiler direktive eingebunden?

[mkinzler]

Versuchs mal den Wert in einer Zwischenvariavle zwischenzuspeichern und den endgültigen wert dann result zuzuweisen.

[sgmeiner]

@Bernhard Geyer: Nein, String und Record bleiben innerhalb der DLL. Die DB-Komponenten brauchen die nur zum internen Datenhandling. Die Daten werden im Fall der betroffenen Funktion nur in ein Textfile geschrieben. Aber soweit komm ich beim zweiten Aufruf meiner Funktion gar nicht mehr. Da scheppert's schon vorher.

@fwsp: Welche Direktive meinst du genau?

@mkinzler: Hab ich auch schon probiert... gleiches Ergebnis. Ich step das aber morgen nochmal gründlich durch

[sgmeiner]

Erstmal danke für die Anregungen. Bin leider noch nicht viel weiter gekommen.

Hab das jetzt nochmal mit einer temporären Variable ausprobiert, wie mkinzler das vorgeschlagen hat. Das Ergebnis ist genau das gleiche. Vielleicht sollte ich nochmal erklären, was die Prozedur macht, in der die AV (write of address 0x00000001) auftritt:

Es handelt sich dabei um eine Tokenizer-Funktion, die das nächste Token für Strings in Anführungszeichen aller Art liefert. Dabei wird immer ein Zeichen aus einem Stream gelesen (ReadChar, siehe Code) und überprüft, ob es mit dem ersten gelesenen übereinstimmt, was ja dann bedeuten würde, dass das Token fertig gelesen ist.

Gut ich hab meine Abfrage mal so umgebaut, dass betreffende Token nicht vorkommt. Achtung, jetzt kommts: bleibe ich unter einer bestimmten "kritischen" Grenze was die Stringlänge betrifft läuft diese Funktion durch, die AV kommt an einer anderen Stelle (andere Funktion, andere String-Variable, beim Aufruf von AnsiUpperCase(CurrentValue), auch wieder Access Violation mit write of address 0x00000001). Es scheint hier wirklich um die Menge der im Speicher für den String reservierten Zeichen zu gehen...

Stichwort Heap-Overflow vielleicht???

Nachtrag: Hab FastMM4 ausprobiert - Absturz bei FastFreeMem während versucht wird das (oder den / die???) Lock aufzuheben. ebx soll wohl eine Referenz auf TSmallBlockType enthalten, enthält aber den Wert 1.