[C++] Geheugenlek bij DLL functie aanroep

[koffercomputer]

Ik heb een applicatie geschreven die een aantal plugin DLL's inlaadt en vervolgens functies uit deze DLL's aanroept. Iedere DLL heeft dezelfde interface.

De pointers naar de verschillende DLL functies staan in een structure, en hiervan heb ik een map gemaakt map<string, interfaceStruct> waarmee ik de naam van de DLL aan zijn functies heb gekoppeld.

Alles werkt voorbeeldig, maar vandaag merkte ik dat mijn PC wat traag begon te worden nadat de applicatie een tijdje actief was. Uit onderzoek bleek dat de applicatie zo'n slordige 2MB per seconde lekt.

Het exacte lekpunt heb ik gevonden, het gaat om een aanroep van een functie met de volgende signature:

code:

void functie(infoStruct)  

waarbij infoStruct

typedef struct
{
    string naam;
    bool input;
    bool output;
} infoStruct

De functie die wordt aangeroepen vult netjes de gegevens in (hardcoded)

code:

void functie(infoStruct &info)
{
    info.naam="naam";
    info.input=false;
    info.output=true;
}

Voor zover ik kan zien zou dit geen geheugen mogen lekken, en ik ben al een hele dag aan het zoeken waar het aan kan liggen. Ik heb diverse manieren geprobeerd om meer informatie over het lek te krijgen, maar ik kan gewoon niets vinden. Waarschijnlijk is het iets heel eenvoudigs, maar ik zie het gewoon niet.

[edit]
Het blijkt dat de overige functies ook lekken.
Ik kwam al iets tegen over het HEAP gebruik van DLL's en applicaties. Maar mijn functie maakt toch geen objecten aan op de HEAP?).

help!

[ Voor 9% gewijzigd door koffercomputer op 23-08-2005 14:20 ]

[.oisyn]

Wat doe je aan heapmanagement? Want met statisch gelinkte runtime libraries heeft elke dll en je hoofd applicatie een eigen heap. Geheugen gealloceerd in een dll kan dus niet vrijgegeven worden in je exe, en er wordt nogal wat geheugen aangemaakt en rondgecopied in classes als std::string.

Je zou tegen dynamische runtime libs kunnen linken, of de new/delete operators overriden om alle geheugenmanagement te deferren naar je executable.

[koffercomputer]

.oisyn, Heap management is mij niet zo bekend, heb je daar een linkje van zodat ik me hierin kan inlezen?

Mijn DLL's worden met LoadLibrary ingeladen, waarna ik met GetProcAddress de functiepointers verkrijg . Dit is toch niet statisch ingelinkt?

Ik kan inzien dat string veel geheugen van hot naar her kopieert, en dat dat dus bij applicatie->dll en andersom niet goed gaat omdat beide een eigen HEAP hebben. Wat kan ik er aan doen om er voor te zorgen dat mijn strings en structures toch goed van de applicatie naar de dll's kunnen gaan?
Zelf zit ik te denken aan het doorgeven van een pointer naar een char* en daar de string in te zetten door middel van memcpy gevolgd door een delete (in de DLL / Applicatie, hangt af van de richting van communicatie) Zou dat kunnen werken?

Nogmaals, ik ben niet op de hoogte van C++ memory management, en zou er graag wat meer van willen weten.

[MSalters]

Simpel gezegd: als je DLL's gebruikt moet je MSVCxx.DLL gebruiken, en niet tegen de statische CRT linken. (/MD, /MDd) Een pointer naar char* doorgeven heeft exact hetzelfde probleem als std::string.

Dit is overigens geen C++ memory management, maar MSVC++ specifiek.

[ Voor 4% gewijzigd door MSalters op 24-08-2005 09:54 ]

[koffercomputer]

Ik gebruik als ontwikkelomgeving dev-cpp met de mingw compiler en libraries.
MSVC spullen heb ik dus niet bij de hand.

Wel heb ik vandaag mijn omgeving bijgewerkt naar de laatste versie.
Het lijkt er op dat het probleem nu is opgelost, maar dat weet ik pas na een paar grondige testrondes.