To fix this problem I developed a patch, which removes this memory leakage from gcrypt package. The patch adds a normal cleanup system, but is not accepted by the gcrypt maintainers for still unexplainable reasons. See the communication of my tries to build your own opinion if you want:
The library uses a function gcry_control() for different tasks (e.g. initialization). This function gets a command type as argument. It already has an argument called GCRYCTL_FINALIZE, which is not yet used. The patch gives this command the usage which finalizes the library cleaning up all the internal allocations and resetting the whole to initial state.
Adding gcry_control(GCRYCTL_FINALIZE); after using the gcrypt library in your application is enough to fix the memory issue.
Compatibility:
Some users of libgcrypt want to use the library in dynamic contexts, which means
dynamically loading and unloading. It may be a good idea to build an destructor for the
library with calls gcry_control(GCRYCTL_FINALIZE) to automatically free the
allocated resources. This call would be perfectly valid also if the library
has not been initialized, as in this case no deallocation would be done.
I do not use it that way and thus did not care for such things, but contrary to
the statements of the libgcrypt maintainers it is possible to use the library
in dynamic loading as well.
In the time since the first release lots of other changes have been
included, which are required to build the software under different
conditions (like on Windows systems). I was not even possible to include
such minor code fixes and BUG fixes into the main library. I generally gave
up to try now and do all the stuff in a patch file updated everytime
conflicts occur. Very seldom some of the fixes have been found by the
libgcrypt developers also and fixed in an comparable way (but my fix was
rejected :-).
The changes include following: