memory leaks

[Marcus Brinkmann]

On Thu, 2006-01-12 at 10:09 +0100, ZIGLIO, Frediano, VF-IT wrote:
> The usual way to fix this issue are mainly two
> 1- use counter
> 2- init library at so init
> 
> 1 is usually preferred (it work even with static library).

Yeah, 1 seems to be better.

> (I not took into account thread problems)

That's not so hard to do, as (1) the first init has to be done before
creating other threads using the library, and (2) all users must agree
on the thread library to use.  So you can implement the necessary mutex.


> Well, current API is just broken for dlopen contexts...

Yes.  Also, the current API is very stable, in the sense that we don't
want to modify it, for the reasons I gave.  This means that we may not
be able to fix this issue for you in the current version.

> Assume that library A call gcry_set_allocation_handler... now any
> time you allocate memory inside libgcrypt you call alloc/free/realloc
> provided by library A. Now what happens if library B calls
> gcry_set_allocation_handler? Well, I think that all these globals should
> be removed (same problem for threadsafe callbacks).

For the thread callbacks, this is not an issue, as you are required to
use the same threadsafe callbacks in all users.  We thought about it,
and we could not think of a credible story where you would use more than
one thread library in a single program.  Do you know one?

Allocation routines are a problem here, yes.

>  
> There are some solution to this problem
> - use only static library, any library that will use libgcrypt use a
> different libgcrypt library (this break ABI where you provide dynamic
> libraries)

You need to elaborate on that.  I suppose you mean linking with some
sort of private scope, where every user gets their own copy of the
library.  This is possible on GNU platforms, as far as I know, but not
at all portable.  Am I wrong?

> - use a single solution (malloc/free/realloc from libc, pthread where
> available) and do not use callbacks (ignoring settings), this keep ABI
> but you can have some problems mixing calls to gcry_malloc/free/realloc
> and "A malloc/free/realloc".

There are good reasons why some people want to avoid linking to pthread,
so we can't just require it.  Also, we want to retain support for GNU
Pth.  These are our design constraints.  We considered creating library
variants "libgcrypt-pthread" etc, but does this really solve anything?
Would users start to introduce libopenldap-pthread, etc?

> - use a session structure to store callbacks and change all API to
> accept this session. This as you can imagine breaks API, however you can
> avoid this using a global session and adding new APIs while old one call
> new one adding global session, something like

Yes.  We are now talking about a new project, though.  Ie, a major
rewrite.  Also, you can't just easily separate everything.  You really
want to share your random pool as much as possible, because otherwise
you will be entropy drained very quickly.

Thanks,
Marcus