memory leaks

[Dirk Stoecker]

Hello,

> > It includes the motivation for the patch, the way to download and apply it 
> > as well as compatibility considerations (and a note for usage in dynamic 
> > loading contexts).
> 
> Your website expresses a lot of frustration.  That is understandable,

Well, I tried to keep the level low. Usually it is very frustrating when 
having a serious problem and being ignored completely. I am 
nevertheless required to have this page released due to the LGPL license 
of libgcrypt.

> It is very important that we untangle unrelated issues.  Your patch
> contains different types of changes intermixed.  One thing you can do to
> push forward this issue is to split your patch into several different
> patches so we can address them individually.

That is a matter of fact, as it contains all the fixes necessary to 
get the stuff running in our environment. I will not spend any amount of 
time to make that perfectly seperated individual fixes when getting 
ignored. I really have not enough time to be wasted.

Remove the finalization calls and the few related lines from the patch 
and you get all the other memory leak based fixes. I will no do it, as I 
need to assume it will get ignored again.

> One such issue is finalization.  It seems to me that your code does not
> handle finalization correctly.  Consider the following case: library bar
> and baz both use libgcrypt.  They both hide this fact from the
> application.  The application uses the library specific initializers
> (bar_init and baz_init) which each initialize libgcrypt.  Under certain
> conditions this is perfectly legit, in fact, it is the only way
> libgrcypt can be used correctly in such a situation.  Now, imagine baz
> comes with a finalizer, which calls the finalizer for gcrypt you added.
> It seems to me from skimming over your patch that in this case gcrypt is
> deinitialized.  This will potentially break bar's use of gcrypt (I did
> not check if it in fact does so).  It thus seems to me that your
> proposed solution in its current form is at best incomplete, and I don't
> see a trivial fix.

An fix would be to have an initialization and finalization counter 
and do delayed finalization. You have better insight into the topic to 
find out, how this would be needed to be implemented, as reference 
counting in the current state with automatic initializer calls is a bit 
complicated.

Or simply forbid libraries to call finalize until a major redesign has 
been done.

> Equally important would be to find a convincing story how such a major
> revision could actually look like.  Moritz does have some ideas about
> how to restructure the code to make it more modular and less dependent
> on global statics.  However, some of the core issues are unresolved.  We
> have some ideas, but I don't think we have actually found the best
> solution yet, and I am not sure what the best solution would look like.

Well, the idea of libgcrypt 2 to have an context based approach will 
hopefully fix the related issues. Enforcing development in this area 
would surely help a lot. But if there is no Alpha or Beta software nobody 
will actually use it, you will not get comments and progress is slow. 
Projects die due to slow developments. Making an alpha release with 
interface description and design issues to solve would be a first step.

> So here is how I suggest we proceed:  If you can identify separate
> issues in your patch, please report them as separate issues, so they can
> be discussed separately.  In particular, I want to understand if your
> finalizer actually correctly solves the problem you identified (see
> above).  Furthermore, I would like to know if you see ways to improve
> the library in its current form without modifying the ABI/API.  Last but
> not least, we can try to envision how an "ideal" libgcrypt would look
> like and see if we can find mechanisms that actually allow to implement
> it.  This list of issues is losely sorted from easy to hard, and from
> high priority to low priority (from my perspective).

I detailed above, why I will not do this. It works for our use as static 
library. I followed the LGPL and released the code. I several times tried
to contact the libgcrypt maintaining and did not succed, so for me the 
case is closed.

The patch is public domain, so you may use it (or parts of it) as you want 
(including the necessarity to claim copyright by GNU). Or you do not.

If there are questions, I will answer them.

Ciao
-- 
http://www.dstoecker.de/ (PGP key available)