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