[C] Geheugen deallocatie afdwingen

[Gonadan]

Ik heb een DLL (niet zelf geschreven) waarvan ik functies aanroep.
Nu blijken die functies niet al het gealloceerde geheugen weer vrij te geven (leak).
Dit is op zich geen probleem alleen roep ik die DLL in mijn programma enkele honderduizenden keren aan.
En dan wordt het wel een probleem, ruim 800MB ram in gebruik vind ik toch wat te gortig.

Is het mogelijk om die functie die ik aanroep te dwingen al zijn geheugen te dealloceren zodra ik het resultaat van hem heb gekregen?

[MTWZZ]

Als je geen pointer naar dat geheugen hebt dan gaat je dat niet lukken voor zover ik weet.
Je kunt wel dit proberen:

C:

free(random());

maar ik betwijfel of je daar ver mee komt

[H!GHGuY]

je zal moeten zoeken naar een manier om die DLL de opdracht te geven zijn geheugen te verwijderen.

Ik had overlaatst het volgende geval in C#:
Een ActiveX component (niet door mij geschreven) opent een bestand.

C#:

myActiveX.Fetch(file);

Ik zet enkele properties op het document en geef de opdracht het ding op te slaan. De component heeft geen Close() oproep dus denk je dat die dingen impliciet gebeuren.
Vervolgens Dispose ik de ActiveX component (zie het als een oproep naar free() ).
Er blijft echter 2MB niet vrijgegeven geheugen staan.

Ik dacht: laten we dan mar iets stom proberen, het zal wel crashen maar je weet nooit.

C#:

myActiveX.Fetch(null);

Werkt het toch wel zeker...
Je moet dus om een bestand te sluiten, opgeven dat ie niets moet openen

als je pointers terugkrijgt van het programma kun je die zelf mooi vrijgeven als je ze niet meer odig hebt. Als het interne datastructuren zijn (waar jij niet aan kan) die lekken, dan heb je een klein probleem denk'k.

[Gonadan]

HIGHGuY schreef op vrijdag 10 maart 2006 @ 10:25:
je zal moeten zoeken naar een manier om die DLL de opdracht te geven zijn geheugen te verwijderen.

Ik had overlaatst het volgende geval in C#:
Een ActiveX component (niet door mij geschreven) opent een bestand.

C#:

myActiveX.Fetch(file);

Ik zet enkele properties op het document en geef de opdracht het ding op te slaan. De component heeft geen Close() oproep dus denk je dat die dingen impliciet gebeuren.
Vervolgens Dispose ik de ActiveX component (zie het als een oproep naar free() ).
Er blijft echter 2MB niet vrijgegeven geheugen staan.

Ik dacht: laten we dan mar iets stom proberen, het zal wel crashen maar je weet nooit.

C#:

myActiveX.Fetch(null);

Werkt het toch wel zeker...
Je moet dus om een bestand te sluiten, opgeven dat ie niets moet openen

als je pointers terugkrijgt van het programma kun je die zelf mooi vrijgeven als je ze niet meer odig hebt. Als het interne datastructuren zijn (waar jij niet aan kan) die lekken, dan heb je een klein probleem denk'k.

Ik heb inderdaad een functie die een pointer geeft, maar die geef ik weer vrij en dat zorgt ook niet voor problemen.

Het is inderdaad een void functie die lekt, dus daarom kon ik ook geen oplossing vinden

[.oisyn]

Dan: nee, dat kan niet

[Gonadan]

.oisyn schreef op vrijdag 10 maart 2006 @ 12:10:
Dan: nee, dat kan niet

Is er echt geen uitweg?

Bijvoorbeeld een thread starten met JNI en hem daarin aanroepen?
Of staat het geheugen dat hij lekt daar compleet los van?

[.oisyn]

geheugenallocaties zijn niet thread-specifiek. Ze zijn zelfs niet module-specifiek, dus je kunt je DLL geen sandbox geven die je aan het eind compleet weggooit (zoals dat bijvoorbeeld met een proces mogelijk is). Je kan hooguit de hele heap destroyen (terwijl je zelf bijvoorbeeld gebruik maakt van een andere heap, zie de win32 Heap* functies hiervoor), maar dan kun je niet verwachten dat de DLL daarna nog werkt.

Of misschien nog een optie is alle allocaties te enumereren voordat je zo'n functie in de DLL aanroept dmv HeapWalk(), en als de functie klaar is dat nog een keer te doen. Het verschil tussen die twee enumeraties bestaat uiteraard uit de allocaties die de functie zelf heeft gedaan en die zou je dan kunnen vrijgeven. Maar nogmaals, je weet niet wat er voor die DLL nodig is om te blijven werken en wellicht verneuk je z'n state door geheugen weg te gooien.

[ Voor 37% gewijzigd door .oisyn op 10-03-2006 12:41 ]

[Gonadan]

Dan ben ik bang dat ik iets moet proberen als er een executable van maken en die weer aanroepen met een ander programma.
Nogal smerig, maar ik zie geen andere optie

Edit:
ik neem aan dat als je het geheugen van de dll sloopt dat hij ook niet meer geladen is?

[ Voor 23% gewijzigd door Gonadan op 10-03-2006 12:43 ]

[.oisyn]

Nee, je moet 'm nog wel vrijgeven dmv FreeLibrary . Beter doe je dat ook eerst voordat je z'n heapobjecten weggooit, wellicht wil ie er nog wat van gebruiken tijdens z'n opruim-fase.

[ Voor 56% gewijzigd door .oisyn op 10-03-2006 12:51 ]

[ATS]

Je zou natuurlijk ook eens contact kunnen opnemen met de bouwer van die DLL...

[Gonadan]

Ik gebruik geen LoadLibrary, ik heb hem meteen gelinked.

C:

...

_declspec(dllexport) BOOL WINAPI _Init(LPSTR);

...

_Init("file");

...

Zo dus

Maar als ik in plaats van dit bij elke aanroep LoadLibrary en FreeLibrary gebruik dan is het nog steeds geen sandboxje wat weer vrijgegeven wordt?

[.oisyn]

Nope.

[The End]

Is er toevallig niet een andere functie in die dll om het geheugen weer vrij te geven?

[Gonadan]

The End schreef op vrijdag 10 maart 2006 @ 14:21:
Is er toevallig niet een andere functie in die dll om het geheugen weer vrij te geven?

Ja, een functie de alles afsluit. En dat is nou net degene die lekt

[Soultaker]

Als de situatie is zoals je schetst is er inderdaad geen mooie oplossing.

Maar hoe weet je zo zeker dat de library lekt en dat jij 'm niet verkeerd gebruikt? Als dit dezelfde library is als waar je in een paar eerdere topics ook mee bezig was, zie ik nog wel aanleiding om te geloven dat je 'm verkeerd aanroept .

[Gonadan]

Soultaker schreef op vrijdag 10 maart 2006 @ 15:11:
Als de situatie is zoals je schetst is er inderdaad geen mooie oplossing.

Maar hoe weet je zo zeker dat de library lekt en dat jij 'm niet verkeerd gebruikt? Als dit dezelfde library is als waar je in een paar eerdere topics ook mee bezig was, zie ik nog wel aanleiding om te geloven dat je 'm verkeerd aanroept .

Begrijpelijk.

Maar je hebt een init, een close en een dataoproep functie.
Kan je weinig aan fout doen, en ik volg ook nog eens precies de handleiding in het gebruik van de functies.
Hij werkt in principe perfect. Totdat ik hem met JNI (of met een for-loopje) heeeeel vaak aanroep.

Ik heb nu een executable gemaakt wat in principe hetzelfde doet als die functie, maar dan is het een laagje er omheen. met Runtime.exec() roep ik die nu heeel vaak aan.
Dit lijkt foutloos te werken, het is alleen boktraag.

[Soultaker]

Heb je al een test-case gebouwt die het lek demonstreert? Ik denk dan aan zoiets:

C:

int main()
{
    while(1) {
        init();
        close();
    }
    return 0;
}

Eventueel met de data-aanroep erbij. Zo ja, kun je die eens posten, samen met de relevante informatie uit de header file die je erbij hebt? (Declaraties van init/close dus, en het commentaar erbij, voor zover dat beschikbaar is.)

Wat doet de library precies en hoe werd 'ie eerder gebruikt? Het lijkt mij dat als het normaal is om enkele honderdduizenden calls te doen, jij niet de eerste bent die het opvalt als de library lekt.

[ Voor 16% gewijzigd door Soultaker op 10-03-2006 15:52 ]

[Gonadan]

Soultaker schreef op vrijdag 10 maart 2006 @ 15:51:
Heb je al een test-case gebouwt die het lek demonstreert? Ik denk dan aan zoiets:

C:

int main()
{
    while(1) {
        init();
        close();
    }
    return 0;
}

Eventueel met de data-aanroep erbij. Zo ja, kun je die eens posten, samen met de relevante informatie uit de header file die je erbij hebt? (Declaraties van init/close dus, en het commentaar erbij, voor zover dat beschikbaar is.)


Wat doet de library precies en hoe werd 'ie eerder gebruikt? Het lijkt mij dat als het normaal is om enkele honderdduizenden calls te doen, jij niet de eerste bent die het opvalt als de library lekt.

ja:

C:

...

_declspec(dllexport) BOOL WINAPI _Init(LPSTR);
_declspec(dllexport) void WINAPI _Close();

...

main()
{
    int i;

    for (i=0; i < 100000; i++) {
       _Init("file");
       _Close();
    }

    return 0;
}

Dit is m'n testcase

offtopic:
Die executable steeds aanroepen duurt uiteindelijk bijna een half uur

[TheBlasphemer]

En je weet zeker dat ook als je dus alleen die testcase doet die je net gepast hebt (dus niets anders!) dat ie ook lekt?

[Gonadan]

TheBlasphemer schreef op vrijdag 10 maart 2006 @ 16:04:
En je weet zeker dat ook als je dus alleen die testcase doet die je net gepast hebt (dus niets anders!) dat ie ook lekt?

Yup, als ik deze testcase gewoon run, dan knalt hij naar zo'n 850MB ramgebruik.
En dat lijkt me niet de bedoeling

Ik heb zelfs ontdekt dat als ik die _Close() weglaat dat het geheugen wel binnen de perken blijft.

[ Voor 14% gewijzigd door Gonadan op 10-03-2006 16:06 ]

[MSalters]

_Init en _Close zijn ook wel verdachte namen. (Gereserveerd voor de compiler + standaard lib) Probeer eens een LoadLibrary, en dan via die pointers de functies aan te roepen.. Dan weet je tenminste zeker wat je in huis haalt.

[Gonadan]

Het zijn ook niet de letterlijke namen.

Maar ik zal het weer eens proberen met GetProcaddress

[RobIII]

Misschien is het de bedoeling dat je die close maar 1 keer aanroept en niet elke keer?
* RobIII roept ook eens wat

[Verwijderd]

Waar komt die library vandaan? (hoe heet ie? wat voor project?)

[ Voor 14% gewijzigd door Verwijderd op 10-03-2006 21:12 ]

[MSalters]

Gonadan schreef op vrijdag 10 maart 2006 @ 20:48:
Het zijn ook niet de letterlijke namen.

Maar ik zal het weer eens proberen met GetProcaddress

Laat maar, de essentie van GetProcAddress was nou juist dat je illegale namen kon vermijden.