Re: [Caml-list] Strategies for finding memory leaks

[Goswin von Brederlow <goswin-v-b@web.de>]

Hans Ole Rafaelsen <hrafaelsen@gmail.com> writes:

> Hello,
>
> Is there some tools / tricks that can be used to help find memory leaks?
>
> I have trouble with an application, that when running for a long time, starts
> to use a lot of CPU and consume more memory. It starts out by using about 20%
> CPU (reported by top) and after 24 hours it has increased to 80% usage. Also
> physical (RES) memory usage goes from 80M to 160M. The workload for the
> application is the same the whole time.
>
> Using OProfile (http://oprofile.sourceforge.net/news/) shows that that most of
> the time is being spent doing memory management.
>
> At startup:
> CPU: Core 2, speed 2667 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask
> of 0x00 (Unhalted core cycles) count 100000
> samples  %        image name               symbol name
> 52764    22.3913  vc_client.native         mark_slice
> 33580    14.2502  vc_client.native         caml_page_table_lookup
> 25415    10.7853  vc_client.native         sweep_slice
> 10119     4.2942  vc_client.native         caml_fl_allocate
> 6423      2.7257  [vdso] (tgid:9015 range:0x7fff4256c000-0x7fff4256d000) [vdso]
> (tgid:9015 range:0x7fff4256c000-0x7fff4256d000)
> 5233      2.2207  vc_client.native        
> camlLividisvc__Nalbuf_tools__replace_pattern_1033
> 2759      1.1708  vc_client.native         caml_iterate_global_roots
> 2728      1.1577  vc_client.native         caml_modify
> 2473      1.0495  vc_client.native         caml_oldify_one
> 2204      0.9353  vc_client.native        
> camlLividisvc__Nalbuf_bytestream__search_1047
> 2183      0.9264  vc_client.native         caml_darken
> 1935      0.8212  vc_client.native         caml_stash_backtrace
> 1843      0.7821  vc_client.native         caml_do_roots
> 1838      0.7800  vc_client.native         caml_delete_global_root
>
> After ca. 24 hours run:
> CPU: Core 2, speed 2667 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask
> of 0x00 (Unhalted core cycles) count 100000
> samples  %        image name               symbol name
> 1137401  56.2697  vc_client.native         mark_slice
> 405598   20.0658  vc_client.native         sweep_slice
> 399832   19.7806  vc_client.native         caml_page_table_lookup
> 10106     0.5000  vc_client.native         caml_fl_allocate
> 3548      0.1755  vc_client.native         caml_iterate_global_roots
> 3397      0.1681  [vdso] (tgid:26129 range:0x7fff747ff000-0x7fff74800000)
> [vdso]
>  (tgid:26129 range:0x7fff747ff000-0x7fff74800000)
> 2797      0.1384  vc_client.native        
> camlLividisvc__Nalbuf_tools__replace_
> pattern_1033
> 2307      0.1141  vc_client.native        
> camlLividisvc__Nalbuf_bytestream__sea
> rch_1047
> 2005      0.0992  vc_client.native         caml_oldify_local_roots
> 1786      0.0884  vc_client.native         caml_gc_stat
> 1441      0.0713  vc_client.native         caml_oldify_one
> 1163      0.0575  vc_client.native         caml_darken
> 1163      0.0575  vc_client.native         caml_fl_merge_block
> 1032      0.0511  vc_client.native         camlHashtbl__find_1093
>
> The application uses several 3rd party libraries, including: LablGTK2,
> OCamlNet, LWT and others.
>
> Is there some clever trick that can by used to track down or get a hint of what
> is causing this?
>
> Thanks,
>
> Hans Ole Rafaelsen

Are you calling the GC manually somewhere in the code or in one of the
libs?

MfG
        Goswin