From: "Gerd Stolpmann" <info@gerd-stolpmann.de>
To: "Hans Ole Rafaelsen" <hrafaelsen@gmail.com>
Cc: "Richard W.M. Jones" <rich@annexia.org>, caml-list@inria.fr
Subject: Re: [Caml-list] Strategies for finding memory leaks
Date: Tue, 3 Apr 2012 12:42:08 +0200 [thread overview]
Message-ID: <a1bc00e7c9117d08c1b486baa1a8abd4.squirrel@gps.dynxs.de> (raw)
In-Reply-To: <CALs4vDbKf3Wgd_nyxEXDwWxDQ4j42gSSWM2aDzR05im+K3TPhQ@mail.gmail.com>
> 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=<size_of_bigarary> and max=256M (hardcoded).
Gerd
>
> Best,
>
> Hans Ole Rafaelsen
>
> On Sun, 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
>> 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.
next prev parent reply other threads:[~2012-04-03 10:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-21 9:49 Hans Ole Rafaelsen
2012-03-22 15:03 ` Goswin von Brederlow
2012-03-23 9:32 ` Hans Ole Rafaelsen
2012-03-24 14:00 ` Goswin von Brederlow
2012-04-01 19:57 ` Richard W.M. Jones
2012-04-02 8:15 ` Hans Ole Rafaelsen
2012-04-02 10:13 ` Richard W.M. Jones
2012-04-02 13:40 ` Hans Ole Rafaelsen
2012-04-02 11:26 ` John Carr
2012-04-03 10:42 ` Gerd Stolpmann [this message]
2012-04-03 12:13 ` Jerome Vouillon
2012-04-04 10:53 ` Hans Ole Rafaelsen
2012-04-04 11:30 ` Gabriel Scherer
2012-04-04 12:55 ` Gerd Stolpmann
2012-04-07 13:27 ` Hans Ole Rafaelsen
2012-04-04 13:55 ` [Caml-list] GC speed for custom blocks, was: " Gerd Stolpmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a1bc00e7c9117d08c1b486baa1a8abd4.squirrel@gps.dynxs.de \
--to=info@gerd-stolpmann.de \
--cc=caml-list@inria.fr \
--cc=hrafaelsen@gmail.com \
--cc=rich@annexia.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox