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 On Friday, September 24, 2021 at 8:44:24 AM UTC-7 Jeffrey Walton wrote: > On Thursday, September 23, 2021 at 4:01:30 PM UTC-4 activis...@gmail.com > wrote: > >> 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 >> <https://www.softwareverify.com/./dl/378054144480b231937bfb5ba3bcd324GuvFXV/MemoryValidatorEvaluationSetup_x64x86.exe>, >> >> 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? >> > > 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 > -- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cryptopp-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/cryptopp-users/b1b4f144-58f9-4f33-aa38-1596b38284b0n%40googlegroups.com.
