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
