Re: Malloc profiler/callgraph

[Eero Tamminen <eero tamminen nokia com>]

Hi,

ext Chris Wilson wrote:
> Recently, Behdad has turned his attention to reducing the number of
> allocations Cairo makes. In order to measure his progress, he wrote a
> tool to hook into malloc and record the callers. Unfortunately in order
> to get the best results, he needed to modify the source. As an
> alternative, I present this valgrind skin. It is mostly based on the
> massif skin, in that it overloads the mallocfree functions and records
> the entire stacktrace and accumulates statistics for each unique trace.
> At the end it will print a table of the allocators (the function that
> called malloc, or rather the first function not listed among --alloc-fn
> ala massif) and it will dump out the unique stack traces to a file.

Have you increased the number of allocation functions you can give?
At least older Valgrind/Massif versions had very small limit on
how many functions could be given.


Btw. When I'm checking where the memory goes in an application that uses
Gtk, I usually ignore most (in extreme cases 90%) of the data in the
stacktraces.  Best is to add a function for which you can give patterns
about functions one wants to skip in the allocation stacktraces.  In the
Gtk app cases I'm usually skipping:
- g_type_*
- g_object_*
- g_signal_*
- g_enum_*
- g_quark_*
- g_param_*
- g_pattern_spec_*
- g_hash_table_*
- g_slist_*
- g_list_*
- g_array_*
- g_mem_*
- closure_*
- gtk_marshal_*
- gtk_binding_*
- _gtk_*
- gtk_container_*
- _main_context_*
- g_slice_*
- FT_Realloc
- FT_Alloc
- FT_QAlloc
- FcStrCopy
- *malloc*
- *realloc*
- *memdup*
- *strdup*

Otherwise you really don't get readable graphs out of the data.


	- Eero