CODEWITHSUNDEEP
c++windowsmemoryvisual-c++memory-leaks
Julian Kirsch
Julian Kirsch

Reputation: 744

Catching memory leaks from libraries

For my current project I am required (i.e. as per requirements) to use an "intricate" in-house library. I quickly recognized, that this library has some memory leaks, which I am unable to fix, for I don't have access to the source code.

Luckily, the only toolchain the project is supposed to work with, is Visual C++ (2017+). So I was wondering, is there anyway to catch all memory allocations, preferably within a block and have those memory blocks released manually?

I was thinking something along the lines of

begin_capture();

BadObject* obj = new BadAllocation();

auto allocations = end_capture();

for(const auto& alloc: allocations)
    delete alloc;

Are there any extensions, specific to Visual C++, or platform-specific libraries, I could use to implement such functionality?

Upvotes: 0

Views: 591

Answers (2)

Artem Razin
Artem Razin

Reputation: 1286

An usual approach is to use a separate process, so when it exits all memory are freed automatically.

If you still want to catch allocations in this 3rd party library (DLL?) you need to realize how does it allocate memory. Suppose, it is written in Visual C++, so all malloc/new calls HeapAlloc. In such case you need to hook HeapAlloc (there are libaries for that: BoxedApp SDK, EasyHook etc.), check that the allocation is made within current thread (by the way, what if the library starts new threads and allocate memory there as well?), store in some list and free all the memory at some point.

So overall I would say it is possible, but using a separate process is a really safer way.

Upvotes: 1

Kuba hasn't forgotten Monica
Kuba hasn't forgotten Monica

Reputation: 98425

The only general solution would be to run the library in a separate process, use shared memory or other IPC (sockets, etc.) to exchange data, and restart the process periodically. If you need to transfer state, you can start a second process, transfer the data from the first to the second (using whatever means necessary, e.g. serializing the library state and then deserializing it on the other end into library calls to rebuild the data), then kill the first one.

Otherwise, insist that this "intricate" library be published to a private git repository (either inhouse or e.g. on github, and surely your job uses version control... right? right?? [don't cry]), add the library source as a third-party submodule into your project's repository (at least you do use version control, right? git repos can be local as you surely know...), and maintain your own branch where you squish memory bugs. No other way around it really. The "intricate" library probably doesn't do anything super-complex, because such low code quality is not usually commensurate with technically advanced functionality. You could probably refactor that library to modern C++ over a year, and forget the whole brouhaha.

If the place that does this magic smoke development can't follow the basic industry practices, such as empowering internal users to fix the code they use, then I suggest it's time to look for another job as soon as you reasonably can. The current one sucks. I'm not joking here.

Upvotes: 1

Related Questions