Trying to track down memory leak(s)

[TamarGranor]

I'm looking for ideas on tracking down memory leaks in an application. Here's the background. I have a VFP EXE (call it UI) that instantiates a VFP COM DLL (call it DL). DL instantiates another VFP COM DLL (call it Online Timer) and a C# DLL (call it Comms). Comms talks to some hardware.

Lots going on here, but the main idea is that we're monitoring and configuring the hardware with this app. Most processing is asynchronous--UI sends a request to DL, which passes it along to Comms. DL also has a timer; when it fires, it asks Comms whether any responses need to be processed. If yes, DL reads the responses, pokes the new data into UI's object model, and tells UI to redraw things. (If you're interested, you can see a couple of the main forms by scrolling down some at

http://www.rflelect.com/exmux.html.)

This week, we noticed that memory usage for UI goes up and up and up. I've left it running overnight each of the last two nights, so I got a run of 12+ hours. Memory went from around 40MB after opening the app and creating the object model to over 110MB by morning.

Here's what I've done so far to track this down:

1) Added a call to SYS(1104) at a place where it will be called regularly.
2) Checked that my objects are getting properly released. There are lots of back and forth object pointers, but I'm cleaning them up appropriately. To confirm this, I tried the trick in Rick Strahl's blog:

http://www.west-wind.com/wconnect/WebLog/ShowEntry.blog?id=692.

When I reach the CLEAR ALL, the only objects left to clear are ones I'd expect.
3) Enhanced the logging I'm already doing to include memory and handle information. I spent today parsing the logs looking for clues. I confirmed two cases where we're adding new objects to collections, so expect memory to go up. That accounts for about 44MB of the 70MB increase. We're making some changes to deal with that.

I can't account for the rest of the increase. In fact, my logs indicate that some of the steps that occasionally (or even, on average) show large increases sometimes show decreases.

4) Googled for VFP memory leaks a few different ways. I found only a couple of items that seemed at all relevant. The most significant is KB #197206, which talks about memory leaks with calls to a VFP COM DLL, but the article is marked as applying to VFP 5 and 6, and hasn't been updated since 1999.

So, I'm looking for ideas about what else could be eating memory. Please, ask any questions that you think relevant.

Tamar

 

[TamarGranor]

Minor correction. DL and Online Timer are COM EXEs, not COM DLLs.

Tamar

 

[GriffMG]

I know it's not probably the best technical solution, but I have a similar problem with a program that, amongst other things, scans PDF files and makes thumbnails.

The 3rd party control I use for this has a memory leak and I find that by counting the number of items processed and restarting the app every N number of iterations I can make it stable.

To do this, I use a shellexecute to load the program a second time and then immediately exit the running copy.

It's pretty much the same approach as I use for auto updates.



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[DSummZZZ]

We have a couple applications in-house that we are having a similar issue with.
They both are hosts for remote connections (WAN) using MS Winsock to accept IP connections, update tables with incoming data, and send replies.
Like Griff, they have to be periodically restarted or they run out of memory.
We haven't been able to pinpoint if the blame lies in using Winsock, but any insight posted here would hopefully be helpful.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[TamarGranor]

I'm not using Winsock, so it's not that. However, elsewhere, I've heard about issues with memory leaks calling to VFP COM objects, so that may be it.

Restarting the app isn't an option here. But I've also been pointed to a technique for releasing memory that VFP is holding. So that may turn out to be the solution. I'll post a link here later.

Tamar

 

[TamarGranor]

Here's the link for the code for reducing VFP's memory allocation:

http://www.foxite.com/faq/default.aspx?id=55

Tamar

 

[DSummZZZ]

Thanks, but we implemented that function a month or so ago. It only delays the inevitable.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[TamarGranor]

Turns out that so far, my tests don't show that code making any difference in my application.

Tamar