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