[Delphi] IRequest interface aanroep geeft memory leak

[porn*]

We zijn bezig met een COM-object dat o.a. webpagina's produceert, wat onder andere gebruik maakt van de IRequest-interface. Wanneer we ook maar IETS via deze interface opvragen, krijgen we een memory leak. Weet iemand hoe dat komt en wat we eraan kunnend doen? Gewoon een simpele toewijzing die bijv. een item van de ServerVariables-collectie opvraagt binnen deze interface leidt al tot memory leaks na enkele tientallen requests...

We hebben al naar updates gekeken en op de MS KB, maar daar valt er niks over te vinden. Zou deze bug nog niet opgemerkt zijn???

[ Voor 30% gewijzigd door porn* op 21-02-2003 16:22 ]

[Creepy]

Je weet 100% zeker dat je eigen COM-Object niet leakt?
En zonder enige code blijft het enigszins gokken wat er mis gaat, maar ik gok dat de mem. leak niet in COM of Delphi zit.

[porn*]

We hebben net, om het 100% zeker te weten, een kaal COM+ object gemaakt, dat NIETS anders doet dan een instantie aanmaken van het MtAspMTS-object. Daarin doen we een assignment van een variabele, die zijn waarde haalt uit de ServerVariables-method van het IRequest-object. Doen we die call niet, of vullen we die variabele met een random string, dan krijgen we GEEN memory leak.

Conclusie: de leak MOET wel in dat object zitten.

[LordLarry]

Zoek even op de MS newsgroepen dan ofzo, misschien staat er daar wat over

[Verwijderd]

Een van de rules is als een com component een string alloceerd dat de caller hem zelf vrij moet geven als ie 'm niet meer nodig heeft, op het moment dat je die zelfde pointer nog een keer mee geeft geeft het component het niet vrij en alloceerd gewoon volgens de rules nieuw geheugen.

[martijn_brinkers]

>> Conclusie: de leak MOET wel in dat object zitten
Is wel een kort door de bocht conclusie. Ik zou de conclusie trekken:
"de manier hoe ik dat object gebruik resulteert in een memory leak"
COM doet bijv. aan reference counting. Stel nu dat je bij de aanroep van het object een referentie doorgeeft naar zichzelf en je in het object zelf een referentie hebt naar het object dat je aan roept. Je krijgt zo een 'dead-lock' omdat ze elkaar aan elkaar refereren. Ik wil hiermee niet zeggen dat jouw conclusie niet klopt maar dat er nog genoeg andere redenen kunnen zijn van de vermeende memory leak. Kan je bijv. testen of jouw object wordt gedelete? Wordt de mem leak steeds groter als je in hetzelfde object die method van IRequest herhaald aan roept?

[porn*]

Yearvieh: Nee hoor, dat hoeft niet. Als ik een normale locale string in Delphi in een method gebruik en ik die toewijs, hoef ik die natuurlijk niet vrij te geven. De ServerVariables-collection uit IRequest is ook gewoon een object met daarin wat strings, dus die hoef ik zelf ook niet vrij te geven. Het enige wat ik dus doe is er een string uit halen!

>>Kan je bijv. testen of jouw object wordt gedelete?
Natuurlijk, kwestie van in de destructor een debug.txt-tje laten schrijven. En geloof me, het object wordt echt vrijgegeven.

>>Ik wil hiermee niet zeggen dat jouw conclusie niet klopt maar dat er nog genoeg andere redenen kunnen zijn van de vermeende memory leak.
Nou, ik kan eigenlijk niks bedenken. Waarom niet? Omdat ik alleen een string ophaal. Roep ik die collectie niet aan, dan is er in het object ook geen leak.

>>Wordt de mem leak steeds groter als je in hetzelfde object die method van IRequest herhaald aan roept?
Ja dan wordt hij steeds groter. Ik heb het object even via ASP aan laten maken, en vervolgens roep ik die asp via een Linux scriptje 1000 keer aan. Gevolg: gebruikte memory pool groeit, en wordt pas vrijgegeven als COM+ het object na de standaard 3 minuten inactief vrijgeeft.

[Verwijderd]

Debug.txt puff
Gewoon http://www.debugserver.com gebruiken werkt perfect!
En werkt zelfs via TelNet en onder Linux Als dat nou niet cool is!

[martijn_brinkers]

Kan je een stukje code laten zien hoe je dat COM object gebruikt?

[porn*]

Het COM-object is een ASP Server Object, dus van type TASPMTSObject.

Delphi:

var str: string;
begin
    str := Request.ServerVariables["HTTP_USER_AGENT"];
end

Zeker is dat het in dat stukje zit, als we de string alleen toewijzen met een normale string, lekt er niets weg. Bijv:

Delphi:

var str: string;
begin
    str := 'testtesttesttesttesttesttesttesttesttesttest';
end

Het gaat ALTIJD fout als er gegevens via een ASP interface worden opgehaald. Bovenstaand voorbeeld via Request maar ook Application of Session object geeft hetzelfde resultaat: memory leak.

Nogmaals: het lek begint pas op te vallen als je het op een drukke webserver draait met veel requests naar het object, omdat het per - zeg ongeveer - 1000 calls maar 8KB weglekt...


Btw: reyer daar ga ik eens naar kijken, tnx!

[ Voor 46% gewijzigd door porn* op 25-02-2003 14:43 ]

[martijn_brinkers]

Kan je een stukje laten zien hoe je aan die Request komt etc. Dat geeft wat meer info