How to deal with memory leak from someone else's driver

I am running a c program on a CentOS 5.5 computer. The program runs a loop that performs tests over and over until told to stop by an external source.

By necessity I am using an old driver for a PCI card that communicates with my test system. Since upgrading from CentOS 4.5 to 5.5 I have noticed I can only loop through my program 175 times. At that time the program halts with an error allocating heap memory. I can watch the memory being used in chunks of 10 to 20 MB each time the program loops and the system just runs out of memory. When I exit the program using Cntrl-C the memory is immediately freed.

I have used Valgrind which indicates the memory leaks are in the old driver. The company that wrote the driver only supports Windows now and they haven't upgraded the driver in over 5 years.

Without the source code is there any way开发者_运维百科 I can free the memory used by the driver each time I loop through my program?

Thanks.

If you declare the access to the test system through the driver inside the loop, this should put it out of scope on 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);
}

It's possible that even though Valgrind shows the leaking allocation as being made within the driver code, the problem is still in your code. This would happen, for example, if the driver provides a "free" or "release" type function which it expects your program to call, and you're not doing that.

Create a new process for each N uses of the driver (~175 should work), and communicate with the parent process via any sort of IPC.

Ugh! Tough one,...

Can write your own memory management, wrapping native OS management, and link the old driver to that? I honesty don't know if it can be done.

Also, you could try explaining the problem to the company that wrote this driver, and nicely asking for the old code.

Good luck =/

Does the driver come as a self-contained component, or is it a library that links to your CRT? If the latter -- which is to say, if it expects to link to malloc() rather than providing its own -- you can override the malloc() it uses by forcing it to link to your own implementation. Once that's done, you control its heap, and you can "restart" the driver without having to kill the process.

This is exactly how we dealt with certain leaky third-party libraries that we needed to link into a consumer product.