• Choose a category
• All
• Classic-Fiction

By Root 1461 0

line number is between parentheses immediately behind the filename. The number between the curly brackets is a counter for the memory allocations. For example, {59} means the 59th allocation in your program since it started. You can use the VC++ _CrtSetBreakAlloc() function to tell the VC++ debug runtime to break into the debugger when a certain allocation is performed. For example, add the following line to the beginning of your main() function to let the debugger break on the 59th allocation:

_CrtSetBreakAlloc(59);

In this leaky program, there are two leaks — the first Simple object that is never deleted and the heap-based integer that it creates. In the Visual C++ debugger output window, you can simply double click on one of the memory leaks and it will automatically jump to that line in your code.

Of course, programs like Microsoft Visual C++ discussed in this section, and Valgrind discussed in the next section can’t actually fix the leak for you — what fun would that be? These tools provide information that you can use to find the actual problem. Normally, that involves stepping through the code to find out where the pointer to an object was overwritten without the original object being released. Some debuggers, like Visual C++, provide “watch point” functionality that can break execution of the program when this occurs.

Finding and Fixing Memory Leaks in Linux with Valgrind

Valgrind is an example of a free open-source tool for Linux that, amongst other things, pinpoints the exact line in your code where a leaked object was allocated.

The following output, generated by running Valgrind on the previous leaky program, pinpoints the exact locations where memory was allocated but never released. Valgrind finds the same two memory leaks — the first Simple object that is never deleted and the heap-based integer that it creates:

==15606== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

==15606== malloc/free: in use at exit: 8 bytes in 2 blocks.

==15606== malloc/free: 4 allocs, 2 frees, 16 bytes allocated.

==15606== For counts of detected errors, rerun with: -v

==15606== searching for pointers to 2 not-freed blocks.

==15606== checked 4455600 bytes.

==15606==

==15606== 4 bytes in 1 blocks are still reachable in loss record 1 of 2

==15606== at 0x4002978F: __builtin_new (vg_replace_malloc.c:172)

==15606== by 0x400297E6: operator new(unsigned) (vg_replace_malloc.c:185)

==15606== by 0x804875B: Simple::Simple() (leaky.cpp:8)

==15606== by 0x8048648: main (leaky.cpp:24)

==15606==

==15606==

==15606== 4 bytes in 1 blocks are definitely lost in loss record 2 of 2

==15606== at 0x4002978F: __builtin_new (vg_replace_malloc.c:172)

==15606== by 0x400297E6: operator new(unsigned) (vg_replace_malloc.c:185)

==15606== by 0x8048633: main (leaky.cpp:24)

==15606== by 0x4031FA46: __libc_start_main (in /lib/libc-2.3.2.so)

==15606==

==15606== LEAK SUMMARY:

==15606== definitely lost: 4 bytes in 1 blocks.

==15606== possibly lost: 0 bytes in 0 blocks.

==15606== still reachable: 4 bytes in 1 blocks.

==15606== suppressed: 0 bytes in 0 blocks.

It is strongly recommended to use smart pointers as much as possible to avoid memory leaks.

Double-Deleting and Invalid Pointers

Once you release memory associated with a pointer using delete, the memory is available for use by other parts of your program. Nothing stops you, however, from attempting to continue to use the pointer, which is now a dangling pointer. Double deletion is also a problem. If you use delete a second time on a pointer, the program could be releasing memory that has since been assigned to another object.

Double deletion and use of already released memory are both hard problems to track down because the symptoms may not show up immediately. If two deletions occur within a relatively short amount of time, the program might work indefinitely because the associated memory is not reused that quickly. Similarly, if a deleted object is used immediately after being deleted, most likely it will still be intact.

Of course, there is no guarantee that