but they add up quickly :-) Recently I started using a packaged called gSoap (http://www.cs.fsu.edu/~engelen/soap.html) and using one of their sample apps I noticed some leaks in it. I verified the memory leaks using purify and communicated them to Robert van Engelen, the author of gSoap. After looking at the stack traces we agreed that the leak is in the OpenSLL code (or so we think). I am including the source code for the sample application. The description of the leaks are in leak{1,2,3}.txt. All leaks originate from the call to: r = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
All 3 leaks share the same stack frame from PEM_read_bio_DHparams down to ASN1_item_ex_d2i(). The first leak is for a BN_ULONG : (BN_ULONG *)OPENSSL_malloc(sizeof(BN_ULONG)*(words+1)); The 2nd leak is for a BIGNUM : if ((ret=(BIGNUM *)OPENSSL_malloc(sizeof(BIGNUM))) == NULL) And the 3rd is for a DH: ret=(DH *)OPENSSL_malloc(sizeof(DH)); I did see the posting for the memory leak fix in SSL_dup called from BIO_read() but I don't see a call to SSL_dup in this stack trace - so I believe this is a different leak. Thanks for your help. p.s. Since all the files are in one directory I build the server as debug and the client as release so they don't step on each other. I know it's not good but I didn't have time to cleanup the way it already was. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
