Speicher reservieren und freigeben in DLLs

[Klaus (Gast)]

Hallo!

Ich habe hier in meinem Projekt 2 DLLs, bei deren Verwendung das 
Programm leider reproduzierbar abstürzt. Und zwar innerhalb der einen 
DLL. An der Stelle des Absturzes soll mittels free Speicher freigegeben 
werden. Ich habe dann etwas nachgeforscht, wo der Speicher reserviert 
wurde. Mir ist dann aufgefallen, dass dies innerhalb einer Funktion der 
anderen DLL geschieht.

Könnte das die Ursache des Problems sein? Muss Speicher immer von dem 
Modul freigegeben werden, wo er reserviert wurde? Oder wovon hängt das 
ab, wann das der Fall sein muss und wann nicht?

Viele Grüße,
Klaus

[Klaus W. (mfgkw)]

Das sollte eigentlich kein Problem sein.
Der mit free() freigegebene Speicher muß im selben
Prozeß allokiert worden sein; in welcher DLL oder im
Hauptprogramm ist egal.

Vielleicht wird er versehentlich zweimal freigegeben?

Viele Grüße,
Klaus

[Thomas K. (muetze1)]

Hängt ganz davon ab, ob es der gleiche Speichermanager ist. Gäbe es nur 
einen, dann bräuchten die ganzen WinAPI Aufrufe (z.B. kernel32.dll) 
keine Buffer und Buffergrößenangaben. Die WinAPI umgeht dies Problem 
grundlegend so, dass sie die Buffer immer vom Aufufer gestellt haben 
will (Ausnahme IMalloc Interface in der Shell).

Es gibt keinen Standard oder Interface für den Abgleich der 
Speichermanager. Und da DLL schlecht vorschreiben können wer sie lädt, 
bringen sie im Normalfall einen Speichermanager mit. Visual Studio 
Projekte referenzieren immer die runtime Library DLL und somit benutzen 
sie indirekt den gleichen Speichermanager, da er in dieser DLL enthalten 
ist.

Aber so oder so ist die Grundsatzregel: Speicher immer dort freigeben wo 
er alloziiert wird. Das bedeutet nicht nur das gleiche Modul sondern im 
Normalfall auch die gleiche Ebene. Finally Anweisungskonstrukte wurde ja 
in vielen C++ Anbietern als eigene Spracherweiterung nachgereicht.

[Rufus Τ. F. (rufus)]

Wird der Speicher mit den CRT-Funktionen (m)alloc und free verwaltet, 
oder vielleicht doch mit den Win32-API-Funktion GlobalAlloc und 
GlobalFree? Die darf man keinesfalls vertauschen.

[Klaus (Gast)]

Danke euch! Es liegt also daran, dass die beiden DLLs jeweils ihren 
eigenen Heap verwalten, da beide statisch gegen die CRT gelinkt sind. 
Und somit jede ihre eigenen Kopie des Speichermanager hat.

Ich werd die Entwickler der DLLs mal ne kleine verbale Watsche (aka 
Bugreport) verpassen :)

[... (Gast)]

Ob statisch oder dynamisch gelinkt spielt keine Rolle. Bei M$ haben die 
DLLs in beiden Fällen ihren eigenen Heap.

CU

[Klaus (Gast)]

... schrieb:
> Ob statisch oder dynamisch gelinkt spielt keine Rolle. Bei M$ haben die
> DLLs in beiden Fällen ihren eigenen Heap.

Oh, wirklich? Das würde meine Theorie durcheinander bringen. Wenn die 
CRT dynamisch (von beiden DLLs die selbe Version) gelinkt wird, dann 
müsste doch für den Prozess, der die DLLs läd nur eine Kopie der 
Heapverwaltung vorhanden sein, oder?  Dafür spricht auch, dass es nicht 
zu einem Absturz kommt, wenn die CRT in beiden DLLs dynamisch eingelinkt 
ist.

[... (Gast)]

Ob bestimmte Code-Segmente mehrfach im Speicher liegen ist völlig egal. 
Interressant ist auf welche Daten-Segmente sie zugreifen.
Auch ein Program, daß überhaupt keine DLLs benutzt, kann mehrere Heaps 
haben.