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
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
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.
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.
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 :)
Ob statisch oder dynamisch gelinkt spielt keine Rolle. Bei M$ haben die DLLs in beiden Fällen ihren eigenen Heap. CU
... 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.
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.