[xmlsec] FW: Free/Destroy versus Memory Leak

[Edward Shallow]

Hi Daniel,

   It does not seem to be libxml2. I just isolated the loop to simply the
libxml2 chores of xmlParseDoc'ing and xmlFreeDoc'ing and the memory looks
much more steady and level. Barely any growth worth mentioning.

   I also tried reinitializing both the xmlsec and libxml2 environments for
each and every call ... Same growth, which is substantial at 40K per
request.

   I did not compile anything myself and assume Igor's binairies for both
libxml2 and xmlsec are good.  http://www.zlatkovic.com/libxml.en.html

Any other ideas ?

Ed

P.S. I just spent months porting the xmlsec app from Linux to Windows
because I couldn't get decent "keys in hardware support (i.e. HSMs and
tokens)" with OpenSSL on Linux. Believe it or not the Microsoft CAPI CSPs
are very stable. I have tried 3 different ones without a hitch using
xmlsec's mscrypto support. I also need Entrust support and Entrust also has
an MS CAPI CSP.

I do not know if the Linux version of the app leaks.



-----Original Message-----
From: Daniel Veillard [mailto:veillard at redhat.com] 
Sent: February 19, 2006 5:56 PM
To: Edward Shallow
Cc: xmlsec at aleksey.com
Subject: Re: [xmlsec] FW: Free/Destroy versus Memory Leak

On Sun, Feb 19, 2006 at 05:35:51PM -0500, Edward Shallow wrote:
>  .. Re-sending ... 1st one bounced ..
>    I have isolated the memory growth to the xmlsec environment by 
> using successively narrower 'quick returns'.
> When I comment out the single xmlsec.xmlSecDSigCtxVerify(dsigCtx, 
> sigNode) call, it grows at only 1/10th the rate ~4K (but still grows).
> 
> Do you have any ideas or suggestions ?

  libxml2 itself has a memory wrapper
    http://xmlsoft.org/xmlmem.html#Debugging
I would assume xmlsec also use xmlMalloc/xmlFree/xmlRealloc so the same
debugging methods could be used.
Also you're running on windows and I have heard just too many horror stories
at this point due to mismatching between precompiled versions of the Windows
libraries being used on a different environment and incompatible memory
allocators that I would check that too.

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/