Bug#524908: libcairo-ocaml-dev: memory leak in Cairo_bigarray
On Thu, 04 Aug 2011 16:52:20 +0200
Oto Havle havle...@gmail.com wrote:
I've found a thread from caml-list archives which suggests that calling
caml_{register/remove}_global_root from custom block finalizers might not be
safe:
http://www.mail-archive.com/caml-list@yquem.inria.fr/msg03746.html
No, this is not the case, quoting Xavier Leroy from that same thread:
I foresee absolutely no problems with registering/unregistering global
roots from a C finalizer. As the manual states, the big no-no in
C functions attached to custom blocks is allocating in the heap,
either directly or via a callback into Caml or by releasing the global
lock. Within a finalizer, you should also refrain from raising an
exception, as this would leave the GC is a bizarre state. But global
roots operations are OK.
--
ygrek
http://ygrek.org.ua/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524908: libcairo-ocaml-dev: memory leak in Cairo_bigarray
Stéphane Glondu wrote:
I can see that cairo_surface_t finalizer is always called when expected.
ml_cairo_image_surface_create_for_data does register a global root, but
caml_{register/remove}_global_root calls are always paired.
The bug scenario in fact involves two custom blocks - cairo_surface_t and
bigarray.
The cairo_surface_t finalizer (ml_final_cairo_surface_t) is called correctly, but the
bigarray finalizer (caml_ba_finalize) is not called at all. The bigarray value somehow
disappears from the OCaml heap. The corresponding bigarray data on the C heap is not reclaimed.
I've found a thread from caml-list archives which suggests that calling
caml_{register/remove}_global_root from custom block finalizers might not be safe:
http://www.mail-archive.com/caml-list@yquem.inria.fr/msg03746.html
I've tried to relate the bug to the OCaml GC. My current idea is as follows:
The custom block
- is always allocated in the major heap
- is reclaimed and finalizer is called in sweep_slice() in major_gc.c
- is also reclaimed in caml_compact_heap() in compact.c - and finalizer is not
called!
compact.c:
310 /* No pointers to the header and no infix header:
311 the object was free. */
312 *p = Make_header (Wosize_ehd (q), Tag_ehd (q), Caml_blue);
313 p += Whsize_ehd (q);
The custom block is manipulated in this part of the GC code (confirmed by inserting a tag
check here, and running bug.ml through the modified ocamlrun). Moreover, the bug does not
appear if Gc.compact is replaced by Gc.full_major.
Maybe someone who really understands OCaml GC code can confirm it?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524908: libcairo-ocaml-dev: memory leak in Cairo_bigarray
tags 524908 - moreinfo tags 524908 + confirmed found 524908 1:1.2.0-2 thanks Le 02/08/2011 21:52, Oto Havle a écrit : [...] Note that I have 32-bit system. I didn't take this into account, and I can indeed reproduce the bug in an up-to-date i386 sid chroot, with version 1:1.2.0-2. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524908: libcairo-ocaml-dev: memory leak in Cairo_bigarray
tags 524908 + help upstream
thanks
Le 03/08/2011 08:22, Stéphane Glondu a écrit :
[...] Note that I have 32-bit system.
I didn't take this into account, and I can indeed reproduce the bug in
an up-to-date i386 sid chroot, with version 1:1.2.0-2.
By looking a bit deeper, I can observe that bug.ml fails on both
bytecode and native, but nobug.ml fails only on native (and succeeds on
bytecode as originally stated in the bug report).
Looking even further at the failing bytecode case, after instrumenting
the code (cairo-ocaml and ocaml GC code), I can see that cairo_surface_t
finalizer is always called when expected.
ml_cairo_image_surface_create_for_data does register a global root, but
caml_{register/remove}_global_root calls are always paired. I tried to
remove the global root registration, and the problem disappears.
By the way, not all the recommendations from the section Living in
harmony with the garbage collector of the manual are respected: there
are many missing CAMLparam*, CAMLlocal* and CAMLreturn* invocations. I
tried to add some, but was unsuccessful in solving the problem.
-dinstr output shows that the same code is generated for both versions,
except for the additional Gc.compact call in nobug.ml.
--
Stéphane
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524908: libcairo-ocaml-dev: memory leak in Cairo_bigarray
tags 524908 + moreinfo thanks On Mon, 20 Apr 2009 20:46:03 +0200, Oto Havle wrote: OCaml programs which create Cairo surfaces via Cairo_bigarray leak memory. Following test program reproduces the bug. The program allocates many 100Mb arrays, but explicit garbage collector invocation should keep the total memory usage low. [...] I cannot reproduce this with version 20090223-5 (current testing), nor with 1:1.2.0-1 (current unstable). Is this bug still relevant? Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524908: libcairo-ocaml-dev: memory leak in Cairo_bigarray
Package: libcairo-ocaml-dev Version: 20070908-1+b2 Severity: normal OCaml programs which create Cairo surfaces via Cairo_bigarray leak memory. Following test program reproduces the bug. The program allocates many 100Mb arrays, but explicit garbage collector invocation should keep the total memory usage low. $ cat bug.ml #use topfind #require bigarray,cairo open Bigarray let test () = let u = Array2.create int8_unsigned c_layout 1 1 in ignore (Cairo_bigarray.of_bigarr_8 u) let () = for k = 1 to 100 do Gc.compact (); test () done $ ocaml bug.ml Out of memory during evaluation. It seems that the OCaml runtime does not free memory associated with the bigarray u. Curiously, following program works as expected. Note the last line of function test, which prevents deallocation of the bigarray in preceding GC run. $ cat nobug.ml #use topfind #require bigarray,cairo open Bigarray let test () = let u = Array2.create int8_unsigned c_layout 1 1 in ignore (Cairo_bigarray.of_bigarr_8 u); Gc.compact (); ignore u let () = for k = 1 to 100 do Gc.compact (); test () done $ ocaml nobug.ml (no output) -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.29-mrkev (SMP w/2 CPU cores) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libcairo-ocaml-dev depends on: ii libcairo-ocaml 20070908-1+b2 OCaml bindings for Cairo ii libcairo2-dev 1.6.4-7 Development files for the Cairo 2D ii liblablgtk2-ocaml-dev 2.10.1-2 OCaml bindings to Gtk+ version 2 ii ocaml-nox [ocaml-nox-3.10. 3.10.2-3 ML language implementation with a libcairo-ocaml-dev recommends no packages. Versions of packages libcairo-ocaml-dev suggests: ii ocaml-findlib 1.2.1-5Management tool for OCaml programm -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
