libgcrypt and patches [CLEANUP_PATCH]

Dirk Stoecker gcrypt at
Mon Sep 5 19:36:21 CEST 2005

On Mon, 5 Sep 2005, Werner Koch wrote:

> On Mon, 5 Sep 2005 11:13:55 +0200 (CEST), Dirk Stoecker said:
> > Ok, I try it again. Attached is a minor patch against current svn, which 
> > uses GCRYCTL_FINALIZE to get a cleanup of the whole library. When this is
> > used, all the loaded memory is freed in a way which (hopefully) brings
> > the system to initial state. It should be possible to reuse the library 
> I still fail to see the need for it.  Why do you want to remove a non
> simple DSO out of your process (which is actually not possible on most
> systems) once it has been loaded?

No. I don't want to remove it. I want to free it's allocated resources. 
libgcrypt dynamically allocates resources. The software I need this for 
has really heavy memory usage including lots of allocations, ...

The points are:

1) Debugging tools to track memory loss cannot and will not distinguish 
   between memory loss on purpose and memory loss due to programming

2) I want the memory back. I have enough other memory troubles. I do not
   need to waste memory, which is only used once in the application.

3) Libraries of whatever kind should be able to free every resource they
   request. It is no good style to forget such stuff.

4) Libgcrypt already has the appropriate command for it, only it is not
   used yet.

5) It's really straightforward and easy. It does not change the interface.
   It only enhances it. If you do not call
   gcry_control(GCRYCTL_FINALIZE, 0);
   nothing changes. If you call it you get the memory back, but can
   nevertheless start to use all the functions again.

So finally: There is nothing speaking against it, but some points for it.

Quoting a mail from July, 1th:

>> 1. The problem is that when FN_gcry_pk_genkey is
>> reached program is stopped, I get the following
>> message: Detected memory leaks! and my library is
>> deployed. 
> I suppose this due to one-time allocation done by libgcrypt. There is
> currently no way of getting rid of these one-time allocations.

Well, now there would be a way to do so.

> Dynamically removing libgcrypt from the process is not supported.

I don't care for that. Only for the memory. But probably this gets a 
possibility afterwards as well, who knows?

 ____  _ _  ____  _ _    _ _  ____
|    |  |  |    |  | \  / |  |    | the cool Gremlin from Bischofswerda
|  __   |   ____|  |  \/  |  |    | WWW:
|    |  |  |       |      |  |    | PGP key available on www page.
|____| _|_ |____| _|_    _|_ |____| I hope AMIGA never stops making fun!

More information about the Gcrypt-devel mailing list