Re: [Caml-list] Memory leaks generated by Scanf.fscanf?

["François Bobot" <francois.bobot@cea.fr>]

On 22/06/2014 19:11, Benoît Vaugon wrote:
> I attach a samll patch based on weak-pointers that seems to solve
> the problem.The Jean-Vincent example now prints something like:

Wow! That's a funny solution, but I'm just afraid that it rely on a bad behavior of the GC that the
first three commits of !22 (https://github.com/ocaml/ocaml/pull/22) correct.

In english terms, what Benoît does:
  - put the key in a weak-set to be able to test if it disappeared
  - create a pair that store the key and the associated value
  - put this pair in a weak set, where it will be reclaimed at the next GC because it is reachable
only through a weak pointer.
  - add a finalizer on the pair that add again the pair in the weak set at each GC
  - stop to add it when the key is not present anymore.


The correction of this algorithm rely on the following (good, IMHO) behavior:
  - A value which have an attached finalizer is marked alive, so an ocaml function can run with this
function and one can make it reachable again.

and the following bad behavior:
  - The weak pointers are cleaned before the marking of finalized pointer.

If the cleaning is done later, the pair is marked, then the key is marked, the key is not removed
from the weak-set, thus the key never disappear.

The fact that "The weak pointers are cleaned before the marking of finalized pointer" is bad mainly
because you don't have anymore the property that if a value disappear from a weak set then it have
been reclaimed and can't be used anymore. Use of (==) and tag in hashconsed values are based on this
property.  Moreover the fact that the cleaning of weak pointer is done during the marking phase can
also lead to a value disappearing from a weak set but not from another.

In conclusion the ephemerons are the real solution for the 4.03 release. For the 4.02 I'm not sure
the added complexity and memory/cpu cost is worse it.

Moreover I don't understand why Scanf.from_channel must be memoized by the library. Can't we say
that the user of the library shouldn't call it twice with the same value? The example of
jean-vincent loddo will work with such API, no? We can also add a new not memoized function.

-- 
François