From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q33AgGR8015020 for ; Tue, 3 Apr 2012 12:42:16 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgEAJPTek/U4xEJjWdsb2JhbABDpjORRyIBAQEBCQkLCRIFJIIJAQEEAW4LBQsFBhgNIUUSBhMJCAEJh2kJB7dZkGYEjVQXiQmSCA X-IronPort-AV: E=Sophos;i="4.75,362,1330902000"; d="scan'208";a="152464965" Received: from moutng.kundenserver.de ([212.227.17.9]) by mail1-smtp-roc.national.inria.fr with ESMTP; 03 Apr 2012 12:42:11 +0200 Received: from office1.lan.sumadev.de (dslb-188-097-004-174.pools.arcor-ip.net [188.97.4.174]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0Lbh0d-1ScqpH3FMp-00lCZy; Tue, 03 Apr 2012 12:42:08 +0200 Received: from gps.dynxs.de (localhost [127.0.0.1]) by office1.lan.sumadev.de (Postfix) with ESMTP id DEFE9C00CF; Tue, 3 Apr 2012 12:42:07 +0200 (CEST) Received: from 178.4.228.154 (SquirrelMail authenticated user gerd) by gps.dynxs.de with HTTP; Tue, 3 Apr 2012 12:42:08 +0200 Message-ID: In-Reply-To: References: <20120401195733.GB15870@annexia.org> Date: Tue, 3 Apr 2012 12:42:08 +0200 From: "Gerd Stolpmann" To: "Hans Ole Rafaelsen" Cc: "Richard W.M. Jones" , caml-list@inria.fr User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Provags-ID: V02:K0:TQMjJm+HnqX31N5LqXSLVtny0Fg6rCEHGLYsfSWLjSa 6Pa1wxK3VBnZX9AmtwmtUpOAsLAktsik4eOgPbGVR254h4jbOL CYI790+OP6VcG5Wgqrh43RAFkXGE1auk482mf8Us5eaRwuV6Fg nXs1z5vaW9EMJtS+ogZVXqnb2F03miJ5Z6SMLe8O1m6+RZGs6O PBmcZbilFm55S6f14crgUKQt1bppx7Jr16sHaEBQuFMcIzJ1cq eenFiUtnxqnNI0eBV5FRWUatjtK1RUTa7ZfObV8jYCxBbbI+EC dyWTXS8GMCp2fkF+5fETaBDlvXbH5h+HWzjH0MT8dwW9iC1+nE wQXHgUg3vpErsxKHG6qqkXFF6gNHbxKhoaES0h2KYmZlKu4aM5 tBf5HcWup5JojGTrkDosNaGiI/K6SHMBa4= Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q33AgGR8015020 Subject: Re: [Caml-list] Strategies for finding memory leaks > Hi, > > We have done some further investigation, and it does not seem to be memory > leakage. The application is a video streaming application, where we use > external processes to encode and decode the video. By configuring it in > different ways, we have found the problem to be in the code that is > reading > the decoded video from an external process and displaying it using > LablGTK2. The previous thought memory leakage seems to be memory used for > buffers when the system is under high load, and this is not reclaimed by > the OS. When running on low frame rate the application does not use more > memory than at startup. > > However, the application still consumes more and more CPU time. And it > seems to happen in the GC. Apart from that, the application seems to be > just fine. So it seems to be something in our code (or in LablGTK) that is > making the GC spend more and more time. Anyone experienced this kind of > problem? This reminds me of a problem I had with a specific C binding (for mysql), years ago. That binding allocated custom blocks with badly chosen parameters used/max (see the docs for caml_alloc_custom in http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html#toc144). If the ratio used/max is > 0, these parameters accelerate the GC. If the custom blocks are frequently allocated, this can have a dramatic effect, even for quite small used/max ratios. The solution was to change the code, and to set used=0 and max=1. This type of problem would match your observation that the GC works more and more the longer the program runs, i.e. the more custom blocks have been allocated. The problem basically also exists with bigarrays - with used= and max=256M (hardcoded). Gerd > > Best, > > Hans Ole Rafaelsen > > On Sun, Apr 1, 2012 at 9:57 PM, Richard W.M. Jones > wrote: > >> >> On Wed, Mar 21, 2012 at 10:49:22AM +0100, Hans Ole Rafaelsen wrote: >> > Hello, >> > >> > Is there some tools / tricks that can be used to help find memory >> leaks? >> [...] >> > The application uses several 3rd party libraries, including: LablGTK2, >> > OCamlNet, LWT and others. >> >> If you suspect a leak in the *C* part of your program or these >> libraries, then I am very successfully using valgrind on my OCaml >> (native) programs to track such leaks. >> >> >> https://github.com/libguestfs/libguestfs/blob/95123a9144edc1ddb3ad67d75276ca3af70eddb8/tests/extra/Makefile.am >> >> Note that several of the programs tested are written in OCaml, and see >> also the 'suppressions' file in the same directory. >> >> However this will not find leaks in OCaml code. Although I was >> pleasantly surprised the other day when valgrind pointed correctly to >> a use of an uninitialized string in some OCaml code. >> >> Rich. >> >> -- >> Richard Jones >> Red Hat >> > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > > -- Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de *** Searching for new projects! Need consulting for system *** programming in Ocaml? Gerd Stolpmann can help you.