EAccessViolation bei ListBox->Items->Add [gelöst]
-
Hast du mal versucht herauszubekommen an welcher Einstellung es wirklich liegt, indem du immer nur eine Einstellung änderts?
-
Ähmm ... ich weiß nicht warum es nicht ankam... für mich ist mein letzter Post eindeutig!
Es lag an: erweiterte CompilerOptionen -> Datenausrichtung -> "Quad Word"
Dieses habe ich jetzt auf "Double Word" gestellt!
-
Ich wusste nur jetzt nicht wie du das festgestellt hast. Es kam mir einfach so unwahrscheinlich vor, dass die Datenausrichtung einen Fehler verursacht. Bei den Runtime-libs oder den Packages-Einstellungen ist das eher schon mal möglich.
Wenn du es aber so festgestellt hast, dann ist es ja ok und wir haben wieder was gelernt.
-
Auch für mich klang das eher nach einer Vermutung, als nach einer Feststellung.
Und bitte nochmal für mich (absolut ungläubig wie ich bin): Wenn Du nur die Datenausrichtung auf QuadWord stellst, ist der Fehler wieder da?
-
Joe_M schrieb:
Und bitte nochmal für mich (absolut ungläubig wie ich bin): Wenn Du nur die Datenausrichtung auf QuadWord stellst, ist der Fehler wieder da?
Ja.
Auch wenn ich nicht weiß weshalb. Es wär wirklich schön, wenn mal jemand eine Theorie dazu hat. Ich würde auch vorgeschlagene Tests machen, weil es mich interessiert was da schiefläuft.
-
Im BCB6 gibt es einen Bug bei den ADO-Komponenten, der ebenfalls mit der Byteausrichtung zusammenhängt. Der führt zwar nicht zu einer Zugriffsverletzung sondern zu einem Speicherleck, aber im Prinzip dürfte es das gleiche Problem sein. Jedenfalls ist die Komponente wohl mit 4-Byte-Ausrichtung kompiliert worden. Wenn jetzt der Header mit anderer Ausrichtung kompiliert wird, verändert sich die Größe der Struktur bzw. Klasse und fordert new unter zu wenig oder mehr Speicher als nötig. Der Rest ist mehr oder weniger undefiniert. Beheben kann man das entweder, indem man die Ausrichtung global in den Projektoptionen umstellt, oder nur im betreffenden Header für die Problemklasse.
#pragma pack(push,4) class TProblemKlasse ... #pragma pack(pop)Warum das Problem nur bei bestimmten Komponenten auftritt entzieht sich meinem Verständnis.
-
Guten Morgen,
@Morris Szylak: Ich hoffe deine Ausführungen richtig verstanden zu haben und habe jetzt Folgendes getestet:
* Projekt->Optionen->erweiterte Compileroptionen->Datenausrichtung->"Quad Word" (64bit) wieder eingestellt
* Header der Problemklasse modifiziert://--------------------------------------------------------------------------- #ifndef NewEACfgH #define NewEACfgH //--------------------------------------------------------------------------- #include <Classes.hpp> #include <Controls.hpp> #include <StdCtrls.hpp> #include <Forms.hpp> #include <Menus.hpp> #include <ExtCtrls.hpp> //--------------------------------------------------------------------------- #pragma pack(push,4) // <= eigene Datenausrichtung festgelegt (32bit - Double Word) class TFormNewEACfg : public TForm { __published: // Komponenten, die von der IDE verwaltet werden //... private: // Benutzerdeklarationen //... public: // Benutzerdeklarationen __fastcall TFormNewEACfg(TComponent* Owner); }; #pragma pack(pop) // <= eigene Datenausrichtung zerstört //--------------------------------------------------------------------------- extern PACKAGE TFormNewEACfg *FormNewEACfg; //--------------------------------------------------------------------------- #endifDer Compiler nimmt das so hin. Die Zugriffsverletzung tritt jedoch immernoch auf. Habe ich etwas falsch gemacht, oder meintest du das so, wie ich es ausgeführt habe?
-
Ne. Die Problemklasse ist nicht dein Formular sondern TListBox bzw. TCustomListBox, im BCB6 zu finden in der stdctrls.hpp.
-
Morris Szyslak schrieb:
Ne. Die Problemklasse ist nicht dein Formular sondern TListBox bzw. TCustomListBox, im BCB6 zu finden in der stdctrls.hpp.
Ahso, gut - ich dachte push und pop gelten dann für alle Komponenten die ich in meine Formular-Klasse aufgenommen habe. Ich hab zwar BCB3, aber ich denke da werde ich die Klassen auch in der stdctrls finden... mache mich gleich an die Arbeit