ShareMem vs. FastShareMem

[himitsu]

Zitat:

Zitat von Baeuerle

Kann der Runtime Error duch speicherleaks entstehen???

Ein Speicherleak kann soeinen Fehler eigentlich nicht auslösen, denn dieses sind ja nur "vergessene" (nicht wieder freigegebene) Speicherblöcke ... warscheinlicher wäre da ein BufferOverlow, oder Speichern in "falschen" Speicherbereichen.

Hast du mal den FullDebugMode getestet?

[Baeuerle]

@rochus: Ja ich habe teilweise in den initialisierungen bzw. finali.. code stehen. warum? Macht das einen unterschied?

[Baeuerle]

@himitsu: habe ich getestet hat mir nur ein paar speicherleaks angezeigt (ca. 80Byte) nciht ganz so schlimm :roll:

[RavenIV]

Zitat:

Zitat von Baeuerle

Was heißt jetzt überall?

Ich habe Sie in der Anwendung.dpr und in der dll.dpr als erste eingetragen. In den weiteren Units habe ich FastMM nicht mehr in die uses eingetragen. So weit ich das verstanden habe muss ich das auch nicht oder doch?

Vielleicht solltest du alle anderen Units in den Uses überprüfen, ob dort irgendwo die Sharemem eingetragen ist...

[himitsu]

[quote="Baeuerle"]Was heißt jetzt überall?
Als erste Unit in den .DPRs reicht eigentlich aus (solange sich nichts anderes am MemoryManagement zu schaffen macht.

Zitat:

Zitat von Baeuerle

@rochus: Ja ich habe teilweise in den initialisierungen bzw. finali.. code stehen. warum? Macht das einen unterschied?

nicht unbedingt ... es kommt darauf ann was, aber normaler Weise sollte es keinen Unterschied machen.

[Baeuerle]

ShareMem ist nirgends eingetragen.

So jetzt mal noch was ganz dummes, kann FastMM 4.66 mit Delphi4 genutzt werden? Ich habe das Projekt nämlich noch nicht nach Delphi2005 portiert.

[himitsu]

Sollte es jedenfalls noch, aber wenn nicht ... hab hier noch ein FastMM v4.26, dieses lief/läuft unter D4.

[Baeuerle]

Ok,

ich bin der sache schon näher gekommen. Folgendes Problem:

In der initialisierung einer Unit wird ein Object erzeugt (TRegister) das Objekt kapselt funktionen aus einer anderen *.dll.

Die *.dll enthält Funktionen von einem Tool das nicht mehr weiter unterstütz wird (nur bis D3). Wenn ich jetzt einen String an das Objekt bzw. die *.dll übergebe kracht es.

Ich könnte jetzt versuchen, das Objekt an einer anderen Stelle zu erzeugen vielleicht geht es dann. Habe auch schon versucht FastMM in die zweite dll einzubinden. bringt leider keinen unterschied.

[Baeuerle]

A :cry:

Habe jetzt aufgegeben und bleibe bei ShareMem funktioniert immerhin !!!

Mit FastMM bekomme ich eine EInvalidPointer Exception aus einer externen dll die nicht von mir stammt und ich somit keine möglichkeit habe etwas zu verändern.

Wenn ich das per try except verhindere kommen noch an anderen stellen Probleme Exceptions hoch. Ich lasse lieber die Finger davon.

Danke für eure bemühungen.

[rochus]

Zitat:

Zitat von Baeuerle

@rochus: Ja ich habe teilweise in den initialisierungen bzw. finali.. code stehen. warum? Macht das einen unterschied?

Hi!

Ja, das könnte was ausmachen. Wenn du meinem Link gefolgt wärst, hättest du folgende Zeilen lesen können:

Zitat:

Zitat von link s.o.

In fact, Delphi executables will die with runtime error 217 when an exception was raised before SysUtils is initialized or after it is finalized. In both situations the regular exception handling is not put in place.

If the error occurs right at your application's startup, check your initialization sections. Try to move code into a later part, e.g. into FormCreate() events.
Otherwise check your units' finalization sections.

Gruß