Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005932OCamlback end (clambda to assembly)public2013-02-25 02:582015-12-11 19:18
Assigned Tofrisch 
PlatformOSOS Version
Product Version4.00.1 
Target VersionFixed in Version 
Summary0005932: Modules can leak memory
DescriptionThough this issue is particularly important with first-class modules, because they are much more frequently allocated and may stay around for a long time, this seems to be a general issue with module code. Here is an example where first-class modules leak memory:

module type S = sig val x : int end

module type T = sig
  include S (* swap *)
  val y : string (* swap *)

let copy (module M : T) = (module M : S)

let alloc () =
  copy (module struct
      let x = 42
      let y = String.create 100_000_000
    end : T)

let main () =
  let m = alloc () in
  Gc.full_major ();
  Gc.print_stat stdout;

let () = ignore (main ())

The GC stats (live words) printed by this example show that even after a full major collection the string "y" in an allocated module stays around after the signature of the module has been constrained to not contain "y" in a presumed copy of the original module. If you swap the two lines marked by the comment "swap" in the above code, the problem goes away, because the compiler is forced to reallocate the constrained module due to a different memory layout and can hence "forget" "y".

The assembly code shows that in the first (buggy) case the compiler merely returns the pointer to the original module in the "copy" function. That's sound in the sense that there will not be a segfault if the target signature is a "prefix" of the source signature. But this will, of course, leak memory. The compiler will correctly allocate a fresh, "smaller" module if the target signature is not a "prefix" of the source.

One could argue that this behavior may be acceptable with file modules, because they have a more "static" feel. But I don't think this is acceptable with first-class or even local modules. Values that have been "constrained away" should not only be inaccessible, they should also be reclaimed by the GC.
TagsNo tags attached.
Attached Files

- Relationships
duplicate of 0005098closed creating module values may lead to memory leaks 

-  Notes
frisch (developer)
2013-02-25 09:43

Closing, as this is a duplicate of 0005098.

- Issue History
Date Modified Username Field Change
2013-02-25 02:58 mottl New Issue
2013-02-25 09:42 frisch Relationship added duplicate of 0005098
2013-02-25 09:43 frisch Note Added: 0008911
2013-02-25 09:43 frisch Status new => resolved
2013-02-25 09:43 frisch Resolution open => duplicate
2013-02-25 09:43 frisch Assigned To => frisch
2015-12-11 19:18 xleroy Status resolved => closed
2017-02-23 16:35 doligez Category OCaml backend (code generation) => Back end (clambda to assembly)
2017-02-23 16:44 doligez Category Back end (clambda to assembly) => back end (clambda to assembly)

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker