Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005932OCamlOCaml backend (code generation)public2013-02-25 02:582013-02-25 09:43
Reportermottl 
Assigned Tofrisch 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionduplicate 
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 *)
end

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;
  m

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
(0008911)
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


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker