> 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 <r...@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 g...@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. -- 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
