Menu
I am using _CrtDumpMemoryLeaks to identify memory leaks in our software. We are using a third party library in a multi-threaded application. This library does have memory leaks and therefore in our tests we want to identify those that ours and discard those we do not have any control over.
We use continuous integration so new functions/algorithms/bug fixes get added all the time.
So the question is - is there a safe way of identifying those leaks that are ours and those that are the third parties library. We though about using allocation numbers but is that safe?
268
How does Memory Allocation work in C? In C language, static and dynamic memory allocation is also known as stack memory and heap memory which are allocated during compile time and run time, respectively. 1. Static Memory Allocation
In C language, static and dynamic memory allocation is also known as stack memory and heap memory which are allocated during compile time and run time, respectively. 1. Static Memory Allocation As we discussed static memory allocation is the allocation of memory for the data variables when the computer programs start.
In Dynamic memory allocation, malloc () and calloc () function only allocates memory but cannot free the memory on their own so this is done using free () method explicitly to release the memory that is not in use to avoid memory leakage.
We use realloc () function to alter/update the size of exiting allocated memory blocks. The function may resize or move the allocated memory blocks to a new location. Similar to all other functions for Dynamic Memory Allocation in C, it returns void pointer. Which points to the address of existing or newly allocated memory.
In a big application I worked on the global new and delete operators were overwritten (eg. see How to properly replace global new & delete operators) and used private heaps (eg. HeapCreate). Third party libraries would use the process heap and thus the allocation would be clearly separated.
Frankly I don't think you can get far with allocation numbers. Using explicit separate heaps for app/libraries (and maybe even have separate per-component heaps within your own app) would be much more manageable. Consider that you can add your own app specific header to each allocated block and thus enable very fancy memory tracking. For example capture the allocation entire call-stack would be possible, for debugging. Enable per-component accounting. Etc etc.
100
You might be able to do this using Mirosoft's heap debugging library without using any third-party solutions. Based on what I learned from a previous question here, you should just make sure that all memory allocated in your code is allocated through a call to _malloc_dbg where the second argument is set to _CLIENT_BLOCK. Then you can set a callback function with _CrtSetDumpClient, and that callback will only receive information about the client blocks that were allocated, not the other ones.
You can easily use the preprocessor to convert all the calls to malloc and free to actually call their debugging versions (e.g. _malloc_dbg); just look at how it's done in crtdbg.h which comes with Visual Studio.
The tricky part for me would be figuring out how to override the new and delete operators to call debugging functions like _malloc_dbg. It might be hard to find a solution where only the news and deletes in your own code are affected, and not in the third-party library.
29
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
