Fixing confirmed memory leaks in CryptoPP?

[The P.E.N.]

Hello fellow coders,

I am working on what is intended as a long running crypto comm application written in c++.  As a consequence there can be NO memory leaks.

I've got the CryptoPP library working just fine to sign and verify signatures but there are memory leaks being reported by Memory Validator from  https://www.softwareverify.com, a pretty powerful and sophisticated program.

All other things flagged by this checking application have proven to be well founded.

In the case of the CryptoPP library there appears to be a leak related to the malloc() at line 77 of dll.cpp.  In addition buried somewhere in the dll there are instances of attempts to use free() to release memory allocated by HeapAlloc.

There are other memory leaking problems, but the most prevalent are the two above,

Is there any interest here in fixing any of this stuff?

Peace,

Pen

[Jeffrey Walton]

Yes, there's always interest in cleaning up the code, including latent memory leaks. We managed to clear many of them but some are still buried in the library.

If I am not mistaken, the existing leaks are due to use of Singleton<T>. Most of these leaks are clear on Unix and Linux. The problem platforms are OS X and Windows because Apple and Microsoft failed to provide Dynamic Initialization and Destruction with Concurrency [1] in a timely manner. I.e., Dynamic Initialization or "magic statics" as Microsoft calls them.

Singleton<T> is here in case you want to look it over: https://github.com/weidai11/cryptopp/blob/master/misc.h#L305-L316. It has some comments about the problem on platforms like Apple and Microsoft.

If the platform does not offer the primitives we need, then we can't do something stronger than the platform.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm

Jeff

[The P.E.N.]

Dear Jeffrey,

Thank you for your prompt and kind attention.

I have already foregone the use of dynamic thread creation for similar reasons.  That is, after program initialization no new threads are ever created.  All I need now are the bare bones functions standing alone to sign, and then verify a message using ECDSA SHA 256 with secp256k1 keys.

Is there any way to do this with CryptoPP?

This is just pure math isn't it?  And if verifiers, string sinks, or whatever have to be allocated as "new," why cannot they be cleanly freed after use in scope? 

 

Peace,

Pen

[Jeffrey Walton]

On Friday, September 24, 2021 at 12:16:22 PM UTC-4 activis...@gmail.com wrote:

I have already foregone the use of dynamic thread creation for similar reasons.  That is, after program initialization no new threads are ever created.  All I need now are the bare bones functions standing alone to sign, and then verify a message using ECDSA SHA 256 with secp256k1 keys.

https://www.cryptopp.com/wiki/Elliptic_Curve_Digital_Signature_Algorithm and https://www.cryptopp.com/wiki/Wrapper_DLL

This is just pure math isn't it?  And if verifiers, string sinks, or whatever have to be allocated as "new," why cannot they be cleanly freed after use in scope? 

https://www.cryptopp.com/wiki/Pipelining#Ownership

Jeff

[The P.E.N.]

Dear Jeffrey,

OK then, I'll give it another shot.  What I need to do is avoid the dll altogether, include just the necessary headers, expressly build in any actually required functions, and especially swear off any pipelining so i can isolate problem points.

Thank you again for your gracious help.

Peace,

Pen