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 q328FbBJ026366 for ; Mon, 2 Apr 2012 10:15:37 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukCAO1feU/RVdK2gGdsb2JhbABEuHwIIgEBCwcCDQcUJ4IJAQEBAwESAiwBGx0BAwELBgUEBw0uIgERAQUBHAYTIodiBQucYgqMFoJxhCo/iHYBAQQLkREElWGOUD2ECw X-IronPort-AV: E=Sophos;i="4.75,355,1330902000"; d="scan'208";a="152247181" Received: from mail-iy0-f182.google.com ([209.85.210.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 02 Apr 2012 10:15:03 +0200 Received: by iahk25 with SMTP id k25so6368542iah.27 for ; Mon, 02 Apr 2012 01:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NS3x8ZvaoWBn49glzQa3VYMqvxFse+LmJbAb/VY/Ijw=; b=gzKkDsrSlebaRbzEKV0futsiusMnKT/KiKGcwYoLrq4HxUAy30YhFyi1pltWZM7sef xJqy3nqF8tkQjrYKybKMPrhyNp0R5U+hVmTS2MXCNz/kH9VfxOUHiYEciTcvZGY+PYPd x8DZsDBxBA/ishoaPV+fEG8+vObIbI4VFotsaewJJFvOAZlJYFIg+bRj+OQYnr7PknQS MTu+lOQcnGAXkD8SzB+YuED4r1lmH/ACll7wTSL9JuUj0cLDa2thAk6tInbHqiCunYz2 SnmjQI0WsNt/mCPtn5qF1gwqJPpwJ0cYK2DAMMSDEd+TSMbVnKlESZB5xgqZGlamE8xv sn4w== MIME-Version: 1.0 Received: by 10.50.194.133 with SMTP id hw5mr4592360igc.57.1333354502681; Mon, 02 Apr 2012 01:15:02 -0700 (PDT) Received: by 10.42.117.67 with HTTP; Mon, 2 Apr 2012 01:15:02 -0700 (PDT) In-Reply-To: <20120401195733.GB15870@annexia.org> References: <20120401195733.GB15870@annexia.org> Date: Mon, 2 Apr 2012 10:15:02 +0200 Message-ID: From: Hans Ole Rafaelsen To: "Richard W.M. Jones" Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=14dae93411e17df29904bcadc974 Subject: Re: [Caml-list] Strategies for finding memory leaks --14dae93411e17df29904bcadc974 Content-Type: text/plain; charset=ISO-8859-1 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? 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 > --14dae93411e17df29904bcadc974 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 i= t in different ways, we have found the problem to be in the code that is re= ading the decoded video from an external process and displaying it using La= blGTK2. The previous thought memory leakage seems to be memory used for buf= fers when the system is under high load, and this is not reclaimed by the O= S. 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 jus= t fine. So it seems to be something in our code (or in LablGTK) that is mak= ing the GC spend more and more time. Anyone experienced this kind of proble= m?

Best,

Hans Ole Rafaelsen

On S= un, Apr 1, 2012 at 9:57 PM, Richard W.M. Jones <rich@annexia.org> 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 leak= s?
[...]
> The application uses several 3rd party libraries, in= cluding: 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://g= ithub.com/libguestfs/libguestfs/blob/95123a9144edc1ddb3ad67d75276ca3af70edd= b8/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. =A0Although 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

--14dae93411e17df29904bcadc974--