malloc/free, DLL, memory leaks

[crazyfwed]

Hello,

I'm investigating memory leaks in my program. And I'd like to investigate one thing.

I have already read on this forum that CVI has its own free() and malloc() functions, and that free() calls don't really free the memory.

So, if I use a DLL built using CodeBlocks (which uses mingw compiler) will CVI "substitute" the free() and malloc() functions with its own function at link time ?

For your information, I link against this DLL using an import library. My CVI version is 2017.

Moreover, if CVI can substitute the functions, would it be different if I don't link using an import library but use LoadLibrary() instead ?

If I ask those questions, this is because I don't have memory leaks if I don't use the DLL.

So, either the problem is in the DLL (or in the way I use the DLL) or the problem is related to CVI through my suggested mechanism.

Thanks in advance.

[rolfk · Accepted solution]

No, that is not how memory management works.

Your MingW DLL will link to its own C runtime library (either statically linked into your DLL or dynamically calling the according MingW C runtime DLL). This C runtime implements all the C runtime functions including malloc(), free() and others usually using the Windows APIs HeapAlloc() or similar. But it often is not a direct call into the Windows API but the runtime library does its own bookkeeping for allocated buffers and may actually prepend its own header to the allocated data block for this. So even if you know that your runtime library malloc() uses HeapAlloc() you can't mix and match different malloc() and free() or its underlaying functions. A block allocated with malloc() in runtime library A needs to be freed with free() from that same runtime library. Anything else is playing Russian roulette. CVI can't go and replace the malloc() and free() linkings in your MingW DLL to map to its own implementation as the fact that two functions have the same name could be coincidence and really call totally different functions or have different side effects when being called.

[crazyfwed]

Thanks to your answer, I have been convinced that the memory leak was real.

I then found an issue in the DLL.

In fact, I was using an old version of GNU matheval library (version 1.1.7 from 2008) and one memory leak has been corrected in 2012.

Because compiling matheval under Windows is a pain, I never deared to update.

Anyway, my problem is solved.