Memory leak in Crypto++ examples?

[Rod]

   Most of the Crypto++ examples invoke "new" inside a constructor call, which doesn't allow a corresponding "delete" to be called.  Does this cause a memory leak?

   Example:
StringSource(pMessage, nMessageSize, true, newStreamTransformationFilter(aes, newStringSink(sEncryptedSegment)));

The code above works, but I was unsure about a memory leak, so I tried putting things on the stack:

StringSinkoSink(sEncryptedSegment); StreamTransformationFilteroFilter(aes, &oSink); StringSource(pMessage, nMessageSize, true, &oFilter);

The revised code crashes with a segmentation fault.

Is there a memory leak with the first form above? If so, how should it be revised to avoid that? Thanks.

Rod

[Ken Rune Helland]

On 03/15/2012 03:27 PM, Rod wrote:
> Most of the Crypto++ examples invoke "new" inside a constructor call, which doesn't allow a corresponding "delete" to be called. Does this cause a memory leak?
>
> Example:
> StringSource(pMessage, nMessageSize, true, new StreamTransformationFilter(aes, new StringSink(sEncryptedSegment)));
>
> The code above works, but I was unsure about a memory leak, so I tried putting things on the stack:
>

> StringSink oSink(sEncryptedSegment); StreamTransformationFilter oFilter(aes, &oSink); StringSource(pMessage, nMessageSize, true, &oFilter);

>
> The revised code crashes with a segmentation fault.
>
> Is there a memory leak with the first form above? If so, how should it be revised to avoid that? Thanks.
>
> Rod
>

I have not read the source, but from your eksample it is clear the
Stringsource expects to "own" the passed StreamTransformationFilter
object and deletes it in its own destruktor.

Likewise the StreamTransformationFilter expects to "own" the StringSink
object.

The error in the second example arises from the Stringsource trying
to delete an object on the stack.

Best regards
KenR

[Geoff Beier]

On Fri, Mar 16, 2012 at 02:55, Ken Rune Helland <ke...@csc.no> wrote:

I have not read the source, but from your eksample it is clear the
Stringsource expects to "own" the passed StreamTransformationFilter
object and deletes it in its own destruktor.

I can't find where I saw it documented, so don't take this as a guarantee, but this pattern is quite common in crypto++. If an object's constructor takes a bare pointer, it generally assumes responsibility for using delete to free that pointer. So make sure you allocate it with the new that corresponds to the delete crypto++ is using. I cannot, offhand, think of a constructor I've seen in the library that doesn't follow this pattern.

Geoff

[Rod]

   Great, thanks!  It's generally concerning when you see a "new" without a corresponding "delete", it might be helpful to have this behavior (implicit destruction of objects passed into the constructor) documented in the wiki.  Thanks for your help.

Rod

--
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-user...@googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.

[Geoff Beier]

On Fri, Mar 16, 2012 at 09:22, Rod <rmonse...@yahoo.com> wrote:

   Great, thanks!  It's generally concerning when you see a "new" without a corresponding "delete", it might be helpful to have this behavior (implicit destruction of objects passed into the constructor) documented in the wiki.  Thanks for your help.

Now I remember where I saw it documented. From 'Readme.txt' included with crypto++:

"""

1. If a constructor for A takes a pointer to an object B (except primitive

types such as int and char), then A owns B and will delete B at A's

destruction.  If a constructor for A takes a reference to an object B,

then the caller retains ownership of B and should not destroy it until

A no longer needs it. 

"""

Geoff

[Jeffrey Walton]

On Mar 16, 9:02 am, Geoff Beier <geoffbe...@gmail.com> wrote:

Try http://cryptopp.svn.sourceforge.net/viewvc/cryptopp/trunk/c5/Readme.txt?revision=532
under "Important Usage Notes".