How to deal with memory leak from another driver

Question

I am running the c program on a CentOS 5.5 computer. The program starts a cycle that runs the tests again and again until it is stopped by an external source.

If necessary, I use the old driver for the PCI card, which communicates with my test system. Since upgrading from CentOS 4.5 to 5.5, I noticed that I can only skip my program 175 times. At this time, the program stops with an error allocating heap memory. I can observe how memory is used in pieces of 10 to 20 MB every time the program loops and the system simply run out of memory. When I exit the program using Cntrl-C, the memory is immediately freed.

I used Valgrind, which indicates that memory leaks are in the old driver. The company that wrote the driver only supports Windows, and they have not updated the driver for more than 5 years.

Without source code, can I free the memory used by the driver every time I go through my program?

Thanks.

Answer 1

If you declare access to the test system through the driver inside the loop, this should remove it from the scope at each iteration.

Something like the following:

char readbuf[512]; for (int i = 0; i < countloops; i++) { int fd = open("/dev/com1", O_RDWR); readbuf = read(fd, sizeof (readbuf)); close (fd); } 

Answer 2

Perhaps, although Valgrind shows the distribution leak as being executed inside the driver code, the problem is still in your code. This will happen, for example, if the driver provides a function of the "free" or "freed" type that it expects from your program, and you do not.

Answer 3

Create a new process for each use of the N driver (~ 175 should work) and interact with the parent process through any type of IPC.

Answer 4

Ugh! Hard,...

Can I write my own memory management, wrap my own OS management and associate the old driver with this? I honestly don't know if this can be done.

In addition, you can try to explain the problem of the company that wrote this driver, and nicely ask for the old code.

Good luck = /

Answer 5

Does the driver come as a standalone component, or is it a library that references your CRT? If the latter, that is, if it expects to associate with malloc () rather than providing its own, you can override the malloc () that it uses, forcing it to refer to your own implementation. After that, you control your heap and you can "restart" the driver without killing the process.

This is how we deal with some leaking third-party libraries that we need to associate with a consumer product.