I certainly hope not! There are a few blocks that are generally left allocated - something to do with Xalan that I have never tracked down. I've never got too fussed, as it's only a couple of hundred bytes and something to do with Xalan initialisation - I.e. it's not a leak that grows, it stays constant however much you use the library.
What you show below on the other hand looks like it's coming from something else. Can you tell me the command line options you are using and whether this is with WinCAPI or OpenSSL? (From memory your are using wincapi without Xalan?)
On the question of DSIGReference - you and Vincent are both spot on the mark. It's owned by DSIGSignature, so if it's still there at the end then something is not being deleted that should be. I will chase that one down tomorrow night as well.
Cheers,
BerinMilan Tomic wrote:
Those are memory leaks that VC6 debugger finds in templatesign.cpp:
Dumping objects ->
{19250} normal block at 0x00EC4F58, 52 bytes long.
Data: <XO 8C7 XO > 58 4F EC 00 38 43 37 00 58 4F EC 00 CD CD CD CD
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {19225} normal block at 0x00EC4F10, 9 bytes long.
Data: <& > 26 61 6D 70 3B 00 00 00 00
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {19223} normal block at 0x00EC4E70, 12 bytes long.
Data: <U T F - 8 > 55 00 54 00 46 00 2D 00 38 00 00 00
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {19222} normal block at 0x00EC4E18, 24 bytes long.
Data: < C7 r! @ > B0 43 37 00 CD CD CD CD 8C 72 21 12 00 40 00 00
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {19221} normal block at 0x00F3B468, 14 bytes long.
Data: <U T F - 8 > 55 00 54 00 46 00 2D 00 38 00 00 00 00 00
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {19220} normal block at 0x00F4E588, 16464 bytes long.
Data: < C7 h > B0 43 37 00 CD CD CD CD 00 00 00 00 68 B4 F3 00
{51} normal block at 0x00374338, 52 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 CD CD CD CD
{45} normal block at 0x00374400, 33 bytes long.
Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD
{44} normal block at 0x00372E18, 40 bytes long.
Data: < |L > 14 7C 4C 10 16 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.
The thread 0x75C has exited with code 0 (0x0).
Are they real?
Best regards,
Milan
-----Original Message----- *From:* Vincent Finn [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, March 23, 2004 12:09 PM *To:* [EMAIL PROTECTED] *Subject:* RE: DSIGReference (free)
No, it's handled by the signature
From the docs.
DSIGSignature::createReference
Creates a new DSIGReference
<file:///C:/Libs/xml-security-c-1.0.0/doc/c/apiDocs/classDSIGReference.html>,
adds it to the list of references handled by the owning DSIGSignature
-----Original Message----- *From:* Milan Tomic [mailto:[EMAIL PROTECTED] *Sent:* 23 March 2004 11:01 *To:* [EMAIL PROTECTED] *Subject:* DSIGReference (free)
Berin,
Should I delete DSIGReference (and when?) returned from DSIGSignature::CreateReference() function? I have this peace of code:
} else { DSIGReference *ref; ref = sig->createReference(MAKE_UNICODE_STRING(""));
DSIGTransformEnvelope *env = ref->appendEnvelopedSignatureTransform(); DSIGTransformC14n *c14 = ref->appendCanonicalizationTransform(CANON_C14NE_NOC); }
I'm reading memory leaks here:
xml-security-c-1.1.0\src\dsig\dsigreference.cpp(254) : {2471} normal block at 0x00F69628, 24 bytes long. Data: < 8$ > F4 9C 90 00 38 24 F9 00 C8 0C FA 00 03 00 00 00 xml-security-c-1.1.0\src\dsig\dsigreference.cpp(189) : {2469} normal block at 0x00F61EF0, 16 bytes long. Data: < > CC CD CD CD 80 96 F6 00 88 96 F6 00 88 96 F6 00 xml-security-c-1.1.0\src\dsig\dsigreference.cpp(211) : {2464} normal block at 0x00F61C78, 12 bytes long. Data: <D > 44 9F 90 00 C8 20 F9 00 C8 0C FA 00
I've tried to delete "ref" variable but failed.
Best regards, Milan
