memory leaks

[Marcus Brinkmann]

On Thu, 2006-01-12 at 09:36 +0100, Dirk Stoecker wrote:
> I am 
> nevertheless required to have this page released due to the LGPL license 
> of libgcrypt.

You are required to comply with the conditions of the LGPL.  These
conditions say nothing about a web page.

> 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.

If you want to have your patches applied to the main tree, then you are
asked to submit patches for separat issues individually, so we can
review them individually and accept/reject/ignore them on an individual
basis.  This also helps you, because you will decrease your chances of
being ignored completely.  You say you don't want to spend any amount of
time to make the patches perfect and separate when getting ignored.
However, why do you expect that we spend this time to make the patches
perfect and separate if we don't even know what they would do?

Developing free software cooperatively is not a game where one party
tries to get the other party to do the work for you.  We did not ask you
to spend the work on these patches without prior discussion what would
be a good way to accomplish your goal.  Consecutively, I think it is a
bit unfair to blame us for not accepting your patches and ignoring your
work.

> 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.

A quick glance shows that this is not true.  For example, there is an
unexplained modification to configure.ac.  If you want a guideline for
what a good policy is to follow when submitting patches, have a look at
what is required from patch submitters to the glibc project.

> > One such issue is finalization.  It seems to me that your code does not
> > handle finalization correctly.
>
> An fix would be to have an initialization and finalization counter 
> and do delayed finalization.

I agree that this sounds like a promising strategy.

> 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.

I don't understand what's complicated about it.  Can you elaborate?

> Well, the idea of libgcrypt 2 to have an context based approach will 
> hopefully fix the related issues.

It might, but it's some time I talked to Moritz about it, and I don't
know if he addressed the shared global resource issues and how.

> Enforcing development in this area would surely help a lot.

Development is not enforced.  It is done voluntarily, and/or funded.

Thanks,
Marcus