I attach a samll patch based on weak-pointers that seems to solve the problem.The Jean-Vincent example now prints something like: Iteration #01: stat called 256 times: live blocks: 788 Iteration #02: stat called 256 times: live blocks: 4866 Iteration #03: stat called 256 times: live blocks: 9712 Iteration #04: stat called 256 times: live blocks: 9467 Iteration #05: stat called 256 times: live blocks: 13099 Iteration #06: stat called 256 times: live blocks: 16865 Iteration #07: stat called 256 times: live blocks: 9463 Iteration #08: stat called 256 times: live blocks: 6833 Iteration #09: stat called 256 times: live blocks: 1290 Iteration #10: stat called 256 times: live blocks: 3831 Iteration #11: stat called 256 times: live blocks: 3831 Iteration #12: stat called 256 times: live blocks: 3831 Iteration #13: stat called 256 times: live blocks: 3833 Iteration #14: stat called 256 times: live blocks: 3829 Iteration #15: stat called 256 times: live blocks: 3829 Iteration #16: stat called 256 times: live blocks: 3829 Iteration #17: stat called 256 times: live blocks: 3829 Iteration #18: stat called 256 times: live blocks: 3829 Iteration #19: stat called 256 times: live blocks: 3829 Iteration #20: stat called 256 times: live blocks: 3829 This patch also preserves the scanf semantics about factorisation of scanning buffers. This property may be verified by running the following code: Scanf.fscanf stdin "%[0-9]" (fun s -> print_endline s);; Gc.compact ();; Scanf.fscanf stdin "\n%d" (fun n -> print_endline (string_of_int n));; Regards, Benoît. Le 20/06/2014 17:35, Gabriel Scherer a écrit : > It looks like ephemerons would be a perfect fit to fix this issue, but > unfortunately they're not yet available. > > It should be possible instead, at each call of the memo function, to > iterate on the table and remove any item for file-descriptor which has > been closed (I don't think checking whether a file-descriptor is > closed is provided by an OCaml-land function right now, but it'd be > easy to add to the runtime). That would make Scanning.from_channel > slower (linear in the number of opened channels, though we could > easily amortize by checking for all N new channels), but remove the > leak, I think. > > > On Fri, Jun 20, 2014 at 3:01 PM, Jeremy Yallop wrote: >> On 20 June 2014 13:29, wrote: >>> working on Marionnet (https://launchpad.net/marionnet), I noticed a serious >>> memory leak making the system unusable after a few tens of minutes. After >>> investigation, the problem seems to be related to Scanf.fscanf. >> It looks like your leak is caused by the 'memo' table in the Scanf >> module that associates a lookahead buffer with each input channel: >> >> https://github.com/ocaml/ocaml/blob/trunk/stdlib/scanf.ml#L393 >> >> as explained by a comment in the Scanf code: >> >> https://github.com/ocaml/ocaml/blob/trunk/stdlib/scanf.ml#L268-L320 >> >> Entries are added to the table for each input channel used for >> scanning, but there's no mechanism for removing entries. This would >> be worth raising on Mantis. >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs