This one I can find. There is a formatter object not being deleted at the tail end of templatesign.
Patch :
cvs -z3 diff templatesign.cpp (in directory C:\prog\SRC\xml-security\c\src\tools\templatesign)
Index: templatesign.cpp
===================================================================
RCS file: /home/cvs/xml-security/c/src/tools/templatesign/templatesign.cpp,v
retrieving revision 1.20
diff -r1.20 templatesign.cpp
1304a1305
> delete gFormatter;
Cheers, Berin
Milan 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
