Measuring heap usage by overriding the C standard library calls - c++

Question

With reference to the following code
#include <cassert>
#include <vector>
#include <dlfcn.h>
#include <limits>
#include <map>
#include <algorithm>
#include <iostream>
using std::cout;
using std::endl;
using std::vector;
/*
* Overload the malloc call
*/
int max_heap_usage = 0;
std::map<uintptr_t, int>& heap_memory_map;
void track_max_usage(std::map<uintptr_t, int> heap_memory_map,
int& max_heap_usage);
void* malloc(size_t size) {
// get the original malloc function call
static auto original_malloc = (decltype(&malloc)) dlsym(RTLD_NEXT, "malloc");
// Get the pointer from malloc
void* pointer = original_malloc(size);
uintptr_t pointer_handle = reinterpret_cast<uintptr_t>(pointer);
// assert that the pointer does not already exist in the memory map
assert("memory should not exist in memory map before allocation" &&
heap_memory_map.find(pointer_handle) == heap_memory_map.end());
// add to bookkeeping
heap_memory_map[pointer_handle] = size;
track_max_usage(heap_memory_map, max_heap_usage);
return pointer;
}
void* calloc(size_t count, size_t size) {
// get the original calloc
static auto original_calloc = (decltype(&calloc)) dlsym(RTLD_NEXT, "calloc");
// get the pointer returned by calloc
void* pointer = original_calloc(count, size);
uintptr_t pointer_handle = reinterpret_cast<uintptr_t>(pointer);
// assert that the memory has not been allocated before
assert("memory should not exist in the memory map before allocation" &&
heap_memory_map.find(pointer_handle) == heap_memory_map.end());
// add to bookkeeping
heap_memory_map[pointer_handle] = size * count;
track_max_usage(heap_memory_map, max_heap_usage);
return pointer;
}
void free(void* ptr) {
// get the original free function
static auto original_free = (decltype(&free)) dlsym(RTLD_NEXT, "free");
uintptr_t pointer_handle = reinterpret_cast<uintptr_t>(ptr);
// assert that the heap memory map already has the pointer
assert("memory to be freed does not exist in the heap memory map" &&
heap_memory_map.find(pointer_handle) != heap_memory_map.end());
// add to bookkeeping
heap_memory_map.erase(pointer_handle);
// free the memory
original_free(ptr);
}
/*
* Inputs: A map containing pointer values and the amount of heap memory used
* after that point
*
* The variable that keeps track of the max memory usage till this
* point
*
* This function updates the variable to have the max value if the current
* memory map dictates that the memory usage is greater than what it was
* before.
*/
void track_max_usage(std::map<uintptr_t, int>& heap_memory_map,
int& max_heap_usage) {
// loop through all keys and add up the values
int sum {0};
for (const auto ele : heap_memory_map) { sum += ele.second; }
// assign to max
max_heap_usage = std::max(max_heap_usage, sum);
}
int main() {
vector<int> vec {1, 2, 3, 4};
for (auto ele : vec) {
cout << ele << endl;
}
cout << "Total heap usage " << max_heap_usage << endl;
return 0;
}
I am trying to override the malloc, calloc and free calls so that anytime there is a heap allocation I can keep track of it. Somehow the vector class does not seem to allocate any memory on the heap. Could someone explain what exactly is going on here? Also how can I go about achieving the desired result?
Thanks!

Answer 1

Your program as posted - call it main.cpp - does not quite compile, so it can't be quite
the program whose disappointing behaviour you would like explained:
error: 'heap_memory_map' declared as reference but not initialized
std::map<uintptr_t, int>& heap_memory_map;
^
And if we fix that by declaring instead:
std::map<uintptr_t, int> heap_memory_map;
we then have a linkage error:
undefined reference to `track_max_usage(std::map<unsigned long, int, std::less<unsigned long>, std::allocator<std::pair<unsigned long const, int> > >, int&)'
because the declaration:
void track_max_usage(std::map<uintptr_t, int> heap_memory_map,
int& max_heap_usage);
does not match the definition:
void track_max_usage(std::map<uintptr_t, int>& heap_memory_map,
int& max_heap_usage) {
...
}
If we fix that also by declaring:
void track_max_usage(std::map<uintptr_t, int>& heap_memory_map,
int& max_heap_usage);
then we successfully compile and link, at least if we're not fussy
about standard conformance:
$ g++ -o prog -std=c++11 -Wall main.cpp -ldl
If we are fussy about Standard conformance:
$ g++ -o prog -std=c++11 -Wall -pedantic main.cpp -ldl
then there remain compilation errors:
main.cpp:20:25: error: declaration of ‘void* malloc(size_t)’ has a different exception specifier
void* malloc(size_t size) {
^
...
/usr/include/stdlib.h:466:14: error: from previous declaration ‘void* malloc(size_t) throw ()’
extern void *malloc (size_t __size) __THROW __attribute_malloc__ __wur;
^
main.cpp: In function ‘void* calloc(size_t, size_t)’:
main.cpp:40:39: error: declaration of ‘void* calloc(size_t, size_t)’ has a different exception specifier
void* calloc(size_t count, size_t size) {
^
...
/usr/include/stdlib.h:468:14: error: from previous declaration ‘void* calloc(size_t, size_t) throw ()’
extern void *calloc (size_t __nmemb, size_t __size)
^
main.cpp: In function ‘void free(void*)’:
main.cpp:60:20: error: declaration of ‘void free(void*)’ has a different exception specifier
void free(void* ptr) {
^
...
/usr/include/stdlib.h:483:13: error: from previous declaration ‘void free(void*) throw ()’
extern void free (void *__ptr) __THROW;
Another couple of passing carps:
int isn't guaranteed to store the size of heap block. Thus the Standard library says:
void* malloc(size_t size);
void* calloc(size_t num, size_t size);
and not:
void* malloc(int size);
void* calloc(int num, int size);
So by rights you'd have:
size_t max_heap_usage = 0;
std::map<uintptr_t, size_t> heap_memory_map;
Further, what you actually want is a map of void *-values to sizes,
and there's no reason at all not to have such a map:
std::map<void *, size_t> heap_memory_map;
Then the refrain:
uintptr_t pointer_handle = reinterpret_cast<uintptr_t>(pointer);
could be dispensed with.
Going with what we've got however (and remembering that we don't
know exactly what you have got) running prog does not simply
fail to tally any heap allocations; it crashes:
$ ./prog
Segmentation fault (core dumped)
If you debug this and peruse the backtrace to the segfault, you'll
see the circular call sequence:
operator new(unsigned long)
__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<unsigned long const, int> > >::allocate /usr/include/c++/5/ext/new_allocator.h 104
std::allocator_traits<std::allocator<std::_Rb_tree_node<std::pair<unsigned long const, int> > > >::allocate /usr/include/c++/5/bits/alloc_traits.h 360
std::_Rb_tree<unsigned long, std::pair<unsigned long const, int>, std::_Select1st<std::pair<unsigned long const, int> >, std::less<unsigned long>, std::allocator<std::pair<unsigned long const, int> > >::_M_get_node /usr/include/c++/5/bits/stl_tree.h 491
std::_Rb_tree<unsigned long, std::pair<unsigned long const, int>, std::_Select1st<std::pair<unsigned long const, int> >, std::less<unsigned long>, std::allocator<std::pair<unsigned long const, int> > >::_M_create_node<std::piecewise_construct_t const&, std::tuple<unsigned long const&>, std::tuple<> >(std::piecewise_construct_t const&, std::tuple<unsigned long const&>&&, std::tuple<>&&) /usr/include/c++/5/bits/stl_tree.h 545
std::_Rb_tree<unsigned long, std::pair<unsigned long const, int>, std::_Select1st<std::pair<unsigned long const, int> >, std::less<unsigned long>, std::allocator<std::pair<unsigned long const, int> > >::_M_emplace_hint_unique<std::piecewise_construct_t const&, std::tuple<unsigned long const&>, std::tuple<> >(std::_Rb_tree_const_iterator<std::pair<unsigned long const, int> >, std::piecewise_construct_t const&, std::tuple<unsigned long const&>&&, std::tuple<>&&) /usr/include/c++/5/bits/stl_tree.h 2170
std::map<unsigned long, int, std::less<unsigned long>, std::allocator<std::pair<unsigned long const, int> > >::operator[] /usr/include/c++/5/bits/stl_map.h 483
malloc /home/imk/develop/so/heap_track_orig/main.cpp 34
operator new(unsigned long)
repeated ad nauseam. So the program is looping until it runs out of stack.
This is due to a fatal logical flaw. You're proceeding on the assumption that all the C++ dynamic memory management
operations in the program will be delegated to the Standard C library facilities
malloc, calloc and free.
Well, at least some of them are, and in particular the calls to operator new
that originate in
heap_memory_map[pointer_handle] = size;
when you allocate a new element of your heap map are delegated to malloc.
Which is your malloc. Which again calls:
heap_memory_map[pointer_handle] = size;
then operator new, then back to malloc, and so on to stack-exhaustion.
That is the fatal logical flaw, but the motivating assumption is also flaky.
The C++ Standard does not require even the default implementations of operator new and
operator delete to delegate respectively to malloc and free. It doesn't
specify any relationship between dynamic memory management in C++ and that of C.
The C++ compiler I'm using here (Linux, GCC) does in fact so delegate, and
probably so does yours, but an implementor might choose to delegate both
malloc/free and new/delete directly to OS APIs.
Don't attempt to roll your own heap-profiling. Use a proper heap-profiler.
For linux, the go-to heap profiler is Valgrind's massif.
Your distro will almost certainly provide a Valgrind package, including massif.
Here's a program that I'm going to profile with massif and check it's max heap usage:
main.cpp
#include <vector>
#include <iostream>
using namespace std;
int main() {
vector<int> vec;
for (int i = 0; i < 1000; ++i) {
vec.push_back(i);
}
for ( ;vec.size(); vec.pop_back()) {}
return 0;
}
Compile and link:
$ g++ -g -o prog -Wall main.cpp
Run valgrind with massif:
$ valgrind --tool=massif ./prog
==6479== Massif, a heap profiler
==6479== Copyright (C) 2003-2015, and GNU GPL'd, by Nicholas Nethercote
==6479== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==6479== Command: ./prog
==6479==
==6479==
The heap-profile is output by default in massif.out.NNNN. I find massif.out.6479
and run:
$ ms_print massif.out.6479 > heap_prof.txt
I look in heap_prof.txt and at line 32 I read:
Number of snapshots: 29
Detailed snapshots: [4, 14, 17, 20, 23, 26 (peak)]
which tells me that heap snapshot #26 shows the peak usage. I scroll to
snapshot #26 and see:
--------------------------------------------------------------------------------
n time(i) total(B) useful-heap(B) extra-heap(B) stacks(B)
--------------------------------------------------------------------------------
24 2,049,029 74,768 74,752 16 0
25 2,069,629 78,872 78,848 24 0
26 2,070,679 78,872 78,848 24 0
99.97% (78,848B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->92.18% (72,704B) 0x4EB91FE: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
| ->92.18% (72,704B) 0x4010608: call_init.part.0 (dl-init.c:72)
| ->92.18% (72,704B) 0x4010719: _dl_init (dl-init.c:30)
| ->92.18% (72,704B) 0x4000D08: ??? (in /lib/x86_64-linux-gnu/ld-2.21.so)
|
->07.79% (6,144B) 0x401788: __gnu_cxx::new_allocator<int>::allocate(unsigned long, void const*) (new_allocator.h:104)
->07.79% (6,144B) 0x401665: __gnu_cxx::__alloc_traits<std::allocator<int> >::allocate(std::allocator<int>&, unsigned long) (alloc_traits.h:182)
->07.79% (6,144B) 0x4014B0: std::_Vector_base<int, std::allocator<int> >::_M_allocate(unsigned long) (stl_vector.h:170)
->07.79% (6,144B) 0x400F59: std::vector<int, std::allocator<int> >::_M_insert_aux(__gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, int const&) (vector.tcc:353)
->07.79% (6,144B) 0x400CC4: std::vector<int, std::allocator<int> >::push_back(int const&) (stl_vector.h:925)
->07.79% (6,144B) 0x400AEC: main (main.cpp:9)
So the program's top recorded heap consumption was 78,872 bytes, of
which (a mere) 6,144 bytes were allocated for my std::vector.

Answer 2

The C++ standard library containers don't use malloc and such directly, they use "allocator" objects, which are generally provided as a template parameter. You can look at providing a custom allocator, or, providing a custom operator new function, if you want to hook into things like this for measurement purposes.