--- title: "Memory Leaks" layout: default permalink: /page_leaks.html ---
Dr. Memory
|
Dr. Memory divides all memory that is still allocated at the time it does its leak scan into 3 categories:
-no_midchunk_new_ok
runtime option.-no_midchunk_inheritance_ok
runtime option.char
[] array in the middle of an allocation and points directly at it. You can suppress Dr. Memory's identification of such mid-allocation pointers, causing them to show up as possible leaks, with the -no_midchunk_string_ok
runtime option.-no_midchunk_size_ok
runtime option.The two categories of leaks ("leaks" and "possible leaks") are further broken down into direct and indirect leaks. An indirect leak is a heap object that is reachable by a pointer to its start address, but with all such pointers originating in leaked objects. Leaks can be thought of as trees, with the top-level object the direct leaks and all child objects indirect leaks. Dr. Memory reports the size of all the child indirect leaks for each direct leak, but does not report a detailed callstack for indirect leaks. If the direct leak is addressed, the indirect leaks should no longer be leaked, making their details unnecessary.
By default, Dr. Memory performs leak checking at application exit, or when a mid-run check is requested via -nudge
(see Applications That Do Not Exit). Nudges can be used to help determine when the last pointer to an allocation was lost, if the callstack of the allocation is not sufficient to pinpoint the error in the source code. Each nudge will perform a full leak scan and by nudging periodically the first instance of a particular leak can be used to identify when the leak occurred.
On Windows, when HeapDestroy is called, any live allocations inside are reported as possible leaks. This can be disabled, since some applications may consider it correct behavior, with the -no_check_leaks_on_destroy
option.
Dr. Memory reports the number of leaks, possible leaks, and still-reachable allocations. The callstack for the allocation of each leak and possible leak is gathered by default and listed with other errors in the results file. To also see all of the reachable allocations, use the -show_reachable
runtime option. Reachable allocations are labeled as REACHABLE LEAK
. By default, without the -show_reachable
option, reachable leak callstacks are not compared to suppressions, in order to reduce overhead.
Here are example lines from Dr. Memory's output summary:
And with -show_reachable
, where the callstack for each still-reachable allocation will be in results.txt:
There are known sources of false positives where a memory allocation may actually be reachable by the application, but Dr. Memory's algorithm will determine that it is unreachable. These cases include:
One known problem comes from using glib's memory allocator. To avoid false positives when using glib, set the following environment variables when running your application: