![]() |
The C++ Debugging Support Library
By Carlo Wood, ©1999 - 2003.
|
In this tutorial you will learn how to make memory allocations «invisible» so that they will not show up in the Allocated memory Overview, how to find information about an allocated memory block given an arbitrary pointer pointing inside it and how to write simple memory-leak detection code.
Sometimes a program can allocate a very large number of memory blocks. Having all of those in the Allocated memory Overview could make it impractically large. Therefore it is possible to remove items from this list.
In the following example we make one allocation invisible by
using the function make_invisible()
:
Compile as: g++ -g -DCWDEBUG test7.1.1.cc -lcwd -o invisible
[download]
#include "sys.h" #include "debug.h" int main(void) { Debug( libcw_do.on() ); Debug( dc::malloc.on() ); int* first = new int; AllocTag2(first, "first"); int* second = new int; AllocTag2(second, "second"); Debug( list_allocations_on(libcw_do) ); Debug( make_invisible(first) ); Debug( list_allocations_on(libcw_do) ); delete second; delete first; return 0; }
The output of this program is
MALLOC : operator new (size = 4) = 0x807b330 MALLOC : operator new (size = 4) = 0x80b3a68 MALLOC : Allocated memory: 53232 bytes in 16 blocks: 0x80b3a68 test7.1.1.cc:12 int; (sz = 4) second 0x807b330 test7.1.1.cc:9 int; (sz = 4) first new[] 0x814ba00 <unknown type>; (sz = 8192) WARNING : Object file /lib/tls/libc.so.6 does not have debug info. Address lookups inside this object file will result in a function name only, not a source file location. malloc 0x814ace0 __fopen_internal <unknown type>; (sz = 352) new[] 0x8144e08 <unknown type>; (sz = 8192) malloc 0x80ed898 __fopen_internal <unknown type>; (sz = 352) new[] 0x80f8fb8 <unknown type>; (sz = 8192) malloc 0x80b2f68 __fopen_internal <unknown type>; (sz = 352) new[] 0x80ea888 <unknown type>; (sz = 8192) malloc 0x80b1cc8 __fopen_internal <unknown type>; (sz = 352) new[] 0x80c66d0 <unknown type>; (sz = 8192) malloc 0x807af28 __fopen_internal <unknown type>; (sz = 352) new[] 0x808d6a8 <unknown type>; (sz = 8192) malloc 0x8055bc8 __fopen_internal <unknown type>; (sz = 352) 0x804d970 <unknown type>; (sz = 1320) 0x804d690 <unknown type>; (sz = 640) MALLOC : Allocated memory: 44684 bytes in 13 blocks: 0x80b3a68 test7.1.1.cc:12 int; (sz = 4) second new[] 0x814ba00 <unknown type>; (sz = 8192) malloc 0x814ace0 __fopen_internal <unknown type>; (sz = 352) new[] 0x8144e08 <unknown type>; (sz = 8192) malloc 0x80ed898 __fopen_internal <unknown type>; (sz = 352) new[] 0x80ea888 <unknown type>; (sz = 8192) malloc 0x80b1cc8 __fopen_internal <unknown type>; (sz = 352) new[] 0x80c66d0 <unknown type>; (sz = 8192) malloc 0x807af28 __fopen_internal <unknown type>; (sz = 352) new[] 0x808d6a8 <unknown type>; (sz = 8192) malloc 0x8055bc8 __fopen_internal <unknown type>; (sz = 352) 0x804d970 <unknown type>; (sz = 1320) 0x804d690 <unknown type>; (sz = 640) MALLOC : delete 0x80b3a68 test7.1.1.cc:12 int; (sz = 4) second
As you can see, the first allocation at line 9 disappeared from the overview after it was made invisible.
Pointer validation at de-allocation is still performed however.
For instance, when we make a mistake when freeing the first int
:
Compile as: g++ -g -DCWDEBUG test7.1.2.cc -lcwd -o coredump
[download]
#include "sys.h"
#include "debug.h"
int main(void)
{
Debug( libcw_do.on() );
Debug( dc::malloc.on() );
int* first = new int;
AllocTag2(first, "first");
int* second = new int;
AllocTag2(second, "second");
Debug( list_allocations_on(libcw_do) );
Debug( make_invisible(first) );
Debug( list_allocations_on(libcw_do) );
delete second;
delete [] first; // Make a deliberate error
return 0;
}
then the output becomes
MALLOC : operator new (size = 4) = 0x807b358 MALLOC : operator new (size = 4) = 0x80b3a90 MALLOC : Allocated memory: 53232 bytes in 16 blocks: 0x80b3a90 test7.1.2.cc:12 int; (sz = 4) second 0x807b358 test7.1.2.cc:9 int; (sz = 4) first new[] 0x814ba28 <unknown type>; (sz = 8192) WARNING : Object file /lib/tls/libc.so.6 does not have debug info. Address lookups inside this object file will result in a function name only, not a source file location. malloc 0x814ad08 __fopen_internal <unknown type>; (sz = 352) new[] 0x8144e30 <unknown type>; (sz = 8192) malloc 0x80ed8c0 __fopen_internal <unknown type>; (sz = 352) new[] 0x80f8fe0 <unknown type>; (sz = 8192) malloc 0x80b2f90 __fopen_internal <unknown type>; (sz = 352) new[] 0x80ea8b0 <unknown type>; (sz = 8192) malloc 0x80b1cf0 __fopen_internal <unknown type>; (sz = 352) new[] 0x80c66f8 <unknown type>; (sz = 8192) malloc 0x807af50 __fopen_internal <unknown type>; (sz = 352) new[] 0x808d6d0 <unknown type>; (sz = 8192) malloc 0x8055bf0 __fopen_internal <unknown type>; (sz = 352) 0x804d970 <unknown type>; (sz = 1320) 0x804d690 <unknown type>; (sz = 640) MALLOC : Allocated memory: 44684 bytes in 13 blocks: 0x80b3a90 test7.1.2.cc:12 int; (sz = 4) second new[] 0x814ba28 <unknown type>; (sz = 8192) malloc 0x814ad08 __fopen_internal <unknown type>; (sz = 352) new[] 0x8144e30 <unknown type>; (sz = 8192) malloc 0x80ed8c0 __fopen_internal <unknown type>; (sz = 352) new[] 0x80ea8b0 <unknown type>; (sz = 8192) malloc 0x80b1cf0 __fopen_internal <unknown type>; (sz = 352) new[] 0x80c66f8 <unknown type>; (sz = 8192) malloc 0x807af50 __fopen_internal <unknown type>; (sz = 352) new[] 0x808d6d0 <unknown type>; (sz = 8192) malloc 0x8055bf0 __fopen_internal <unknown type>; (sz = 352) 0x804d970 <unknown type>; (sz = 1320) 0x804d690 <unknown type>; (sz = 640) MALLOC : delete 0x80b3a90 test7.1.2.cc:12 int; (sz = 4) second COREDUMP: You are `delete[]'-ing a block that was allocated with `new'! Use `delete' instead.
Also the function test_delete()
still works:
Compile as: g++ -g -DCWDEBUG test7.1.3.cc -lcwd -o test_delete
[download]
#include "sys.h" #include "debug.h" int main(void) { Debug( libcw_do.on() ); Debug( dc::malloc.on() ); Debug( dc::notice.on() ); void* p = malloc(3000); Debug( make_invisible(p) ); Debug( list_allocations_on(libcw_do) ); Dout(dc::notice, "test_delete(" << p << ") = " << test_delete(p)); free(p); Dout(dc::notice, "test_delete(" << p << ") = " << test_delete(p)); return 0; }
results in
MALLOC : malloc(3000) = 0x817f778 MALLOC : Allocated memory: 53224 bytes in 14 blocks: new[] 0x814cd50 <unknown type>; (sz = 8192) WARNING : Object file /lib/tls/libc.so.6 does not have debug info. Address lookups inside this object file will result in a function name only, not a source file location. malloc 0x814c030 __fopen_internal <unknown type>; (sz = 352) new[] 0x8146158 <unknown type>; (sz = 8192) malloc 0x80eebe8 __fopen_internal <unknown type>; (sz = 352) new[] 0x80fa308 <unknown type>; (sz = 8192) malloc 0x80b4190 __fopen_internal <unknown type>; (sz = 352) new[] 0x80ebbd8 <unknown type>; (sz = 8192) malloc 0x80b2f38 __fopen_internal <unknown type>; (sz = 352) new[] 0x80c7a20 <unknown type>; (sz = 8192) malloc 0x807c278 __fopen_internal <unknown type>; (sz = 352) new[] 0x808e9f8 <unknown type>; (sz = 8192) malloc 0x8056f60 __fopen_internal <unknown type>; (sz = 352) 0x804e970 <unknown type>; (sz = 1320) 0x804e690 <unknown type>; (sz = 640) NOTICE : test_delete(0x817f778) = 0 NOTICE : test_delete(0x817f778) = 1
However, find_alloc()
, the function that is explained in the next paragraph,
will fail to find an «invisible» block (it will return NULL
).
Libcwd allows the developer to generate powerful debugging output; aside from being able to test
if a given pointer points to the start of an allocated memory block, using test_delete()
,
it is even possible to find all information about an allocated memory block that is also shown in the Allocated memory Overview
when given a pointer pointing anywhere inside an allocated memory block. For example:
Compile as: g++ -g -DCWDEBUG test7.2.1.cc -lcwd -o find_alloc
[download]
#include "sys.h" #include "debug.h" using namespace libcwd; template<typename T1, typename T2> struct Foo { T1 for_me; T2 for_you; double d; }; int main(void) { Debug( libcw_do.on() ); Debug( dc::malloc.on() ); Debug( dc::notice.on() ); Foo<char, int>* f = new Foo<char, int>; AllocTag(f, "Our test object"); int* p = &f->for_you; // Pointer that points inside `f' Dout(dc::notice, "f == " << static_cast<void*>(f)); Dout(dc::notice, "p == " << static_cast<void*>(p)); #ifdef CWDEBUG alloc_ct const* alloc = find_alloc(p); Dout(dc::notice, "p points inside \"" << alloc->description() << "\" starting at " << alloc->start() << " with size " << alloc->size() << '.'); Dout(dc::notice, "This memory block contains a \"" << alloc->type_info().demangled_name() << "\"."); Dout(dc::notice, "The allocation type is `" << alloc->memblk_type() << "' and was allocated at " << alloc->location() << '.'); #endif return 0; }
The output of this program is
MALLOC : operator new (size = 16) = 0x8109f18 NOTICE : f == 0x8109f18 NOTICE : p == 0x8109f1c NOTICE : p points inside "Our test object" starting at 0x8109f18 with size 16. NOTICE : This memory block contains a "Foo<char, int>*". NOTICE : The allocation type is `memblk_type_new' and was allocated at test7.2.1.cc:19.
Note that the type returned by alloc->type_info().demangled_name()
is
the type of the pointer passed to AllocTag()
:
This string will always end on a '*'
.
The original reason for supporting pointers that point inside a memory block
and not just to the start of it, was so that it could be used in base classes of objects
derived with multiple inheritance: find_alloc(this)
will
always return the correct memory block, even if there is an offset between this
and the real start of the allocated block.
The same holds for arrays of objects allocated with new[]
.
It is also possible to get the values for the number of bytes and blocks allocated in total, as is printed at the top of each Allocated memory Overview. See the next paragraph.
mem_blocks()
and mem_size()
(like everything else defined in namespace libcwd
)
can be used to write a very simply memory leak detection system:
Compile as: g++ -g -DCWDEBUG test7.3.1.cc -lcwd -o total_alloc
[download]
#include "sys.h" #include "debug.h" using namespace libcwd; int main(void) { Debug( libcw_do.on() ); Debug( dc::malloc.on() ); char* memory_leak = new char [300]; AllocTag(memory_leak, "memory_leak"); // Debug( make_invisible(memory_leak) ); #ifdef CWDEBUG if (mem_blocks() > 0) Dout(dc::warning, "There are still " << mem_size() << " bytes allocated!"); else Dout(dc::malloc, "No memory leaks."); #endif return 0; }
The output of this program is:
MALLOC : operator new[] (size = 300) = 0x80553d8 WARNING : There are still 53524 bytes allocated!
Invisible blocks are not detected!
When you comment out the Debug( make_invisible(memory_leak) );
then
the output will read
MALLOC : operator new[] (size = 300) = 0x804fc88 MALLOC : No memory leaks.
This allows you to improve the memory leak detection a bit in the case of global objects that allocate memory. Nevertheless, that is bad coding: you shouldn't define global objects that allocate memory.
Here is an example program anyway:
Compile as: g++ -g -DCWDEBUG test7.3.2.cc -lcwd -o memleak
[download]
#include "sys.h" #include "debug.h" class A { private: char* dynamic_memory; public: A(void) { dynamic_memory = new char [300]; AllocTag(dynamic_memory, "A::dynamic_memory"); } ~A() { if (dynamic_memory) delete [] dynamic_memory; } }; // Global object that allocates memory (bad programming!) A a; int main(void) { Debug( libcw_do.on() ); Debug( dc::malloc.on() ); #ifdef CWDEBUG if (libcwd::mem_blocks() > 0) { Dout(dc::malloc|dc::warning, "Memory leak"); Debug( list_allocations_on(libcw_do) ); } else Dout(dc::malloc, "No memory leaks."); #endif return 0; }
results in
MALLOC : Memory leak MALLOC : Allocated memory: 53524 bytes in 15 blocks: new[] 0x810c010 test7.3.2.cc:10 char[300]; (sz = 300) A::dynamic_memory new[] 0x815cb40 <unknown type>; (sz = 8192) WARNING : Object file /lib/tls/libc.so.6 does not have debug info. Address lookups inside this object file will result in a function name only, not a source file location. malloc 0x810be50 __fopen_internal <unknown type>; (sz = 352) new[] 0x8156170 <unknown type>; (sz = 8192) malloc 0x8109470 __fopen_internal <unknown type>; (sz = 352) new[] 0x8109d18 <unknown type>; (sz = 8192) malloc 0x80c4778 __fopen_internal <unknown type>; (sz = 352) new[] 0x80fe8c8 <unknown type>; (sz = 8192) malloc 0x80c29b0 __fopen_internal <unknown type>; (sz = 352) new[] 0x80d9ee0 <unknown type>; (sz = 8192) malloc 0x808d068 __fopen_internal <unknown type>; (sz = 352) new[] 0x809e040 <unknown type>; (sz = 8192) malloc 0x8064448 __fopen_internal <unknown type>; (sz = 352) 0x8055970 <unknown type>; (sz = 1320) 0x8055690 <unknown type>; (sz = 640) MALLOC : delete[] 0x810c010 test7.3.2.cc:10 char[300]; (sz = 300) A::dynamic_memory
simply because A::dynamic_memory
is not deleted until after main
.
A simple kludge is to make all memory allocated before main
, invisible:
Compile as: g++ -g -DCWDEBUG test7.3.3.cc -lcwd -o memleak2
[download]
#include "sys.h"
#include "debug.h"
class A {
private:
char* dynamic_memory;
public:
A(void)
{
dynamic_memory = new char [300];
AllocTag(dynamic_memory, "A::dynamic_memory");
}
~A()
{
if (dynamic_memory)
delete [] dynamic_memory;
}
};
// Global object that allocates memory (bad programming!)
A a;
int main(void)
{
Debug( make_all_allocations_invisible_except(NULL) );
Debug( libcw_do.on() );
Debug( dc::malloc.on() );
#ifdef CWDEBUG
if (libcwd::mem_blocks() > 0)
{
Dout(dc::malloc|dc::warning, "Memory leak");
Debug( list_allocations_on(libcw_do) );
}
else
Dout(dc::malloc, "No memory leaks.");
#endif
return 0;
}
which will simply output
MALLOC : No memory leaks.
Libcwd provides an alternative way to check for memory leaks using so called «markers». A marker is like a directory, any allocation made after a marker is created is put into that directory. When a marker is removed and there are still allocation inside it, you will get a warning! In the following example we allocate a memory block, then set a marker and next allocate two more memory blocks.  The Allocated memory Overview is then printed.
Compile as: g++ -g -DCWDEBUG test7.3.4.cc -lcwd -o marker
[download]
#include "sys.h" #include "debug.h" int main(void) { Debug( make_all_allocations_invisible_except(NULL) ); Debug( libcw_do.on() ); Debug( dc::malloc.on() ); int* p1 = new int [10]; AllocTag(p1, "p1"); #if CWDEBUG_MARKER libcwd::marker_ct* marker = new libcwd::marker_ct("A test marker"); #endif int* p2 = new int [20]; AllocTag(p2, "p2"); int* p3 = new int [30]; AllocTag(p3, "p3"); Debug( list_allocations_on(libcw_do) ); #if CWDEBUG_MARKER // Delete the marker while there are still allocations inside it delete marker; #endif return 0; }
The output of this program is:
MALLOC : operator new[] (size = 40) = 0x8055ea8 MALLOC : operator new (size = 8) = 0x8055950 MALLOC : New libcwd::marker_ct at 0x8055950 MALLOC : operator new[] (size = 80) = 0x80c2a80 MALLOC : operator new[] (size = 120) = 0x8109460 MALLOC : Allocated memory: 248 bytes in 4 blocks: (MARKER) 0x8055950 test7.3.4.cc:14 <marker>; (sz = 8) A test marker new[] 0x8109460 test7.3.4.cc:20 int[30]; (sz = 120) p3 new[] 0x80c2a80 test7.3.4.cc:17 int[20]; (sz = 80) p2 new[] 0x8055ea8 test7.3.4.cc:10 int[10]; (sz = 40) p1 MALLOC : Removing libcwd::marker_ct at 0x8055950 (A test marker) * WARNING : Memory leak detected! * new[] 0x8109460 test7.3.4.cc:20 int[30]; (sz = 120) p3 * new[] 0x80c2a80 test7.3.4.cc:17 int[20]; (sz = 80) p2 MALLOC : delete 0x8055950 test7.3.4.cc:14 <marker>; (sz = 8) A test marker
Individual allocations (or other markers, inclusive everything they contain)
can be moved outside a marker with the function move_outside()
.
For example, we could move the allocation of p2
outside our marker:
Compile as: g++ -g -DCWDEBUG test7.3.5.cc -lcwd -o marker2
[download]
#include "sys.h" #include "debug.h" int main(void) { Debug( make_all_allocations_invisible_except(NULL) ); Debug( libcw_do.on() ); Debug( dc::malloc.on() ); int* p1 = new int [10]; AllocTag(p1, "p1"); #if CWDEBUG_MARKER libcwd::marker_ct* marker = new libcwd::marker_ct("A test marker"); #endif int* p2 = new int [20]; AllocTag(p2, "p2"); int* p3 = new int [30]; AllocTag(p3, "p3"); #if CWDEBUG_MARKER Debug( move_outside(marker, p2) ); #endif Debug( list_allocations_on(libcw_do) ); #if CWDEBUG_MARKER // Delete the marker while there are still allocations inside it delete marker; #endif return 0; }
which results in the output
MALLOC : operator new[] (size = 40) = 0x8055ea8 MALLOC : operator new (size = 8) = 0x8055950 MALLOC : New libcwd::marker_ct at 0x8055950 MALLOC : operator new[] (size = 80) = 0x80c3d60 MALLOC : operator new[] (size = 120) = 0x810bdd0 MALLOC : Allocated memory: 248 bytes in 4 blocks: new[] 0x80c3d60 test7.3.5.cc:17 int[20]; (sz = 80) p2 (MARKER) 0x8055950 test7.3.5.cc:14 <marker>; (sz = 8) A test marker new[] 0x810bdd0 test7.3.5.cc:20 int[30]; (sz = 120) p3 new[] 0x8055ea8 test7.3.5.cc:10 int[10]; (sz = 40) p1 MALLOC : Removing libcwd::marker_ct at 0x8055950 (A test marker) * WARNING : Memory leak detected! * new[] 0x810bdd0 test7.3.5.cc:20 int[30]; (sz = 120) p3 MALLOC : delete 0x8055950 test7.3.5.cc:14 <marker>; (sz = 8) A test marker