VFP 调用.NET COM 内存泄漏

[iswithzhz]

In recent years, I have extensively utilized the resources of the .NET framework to create COM components for VFP to call. However, in the actual usage process, I've found that there are serious memory leak issues when some of these COM components are invoked by VFP. Even after performing numerous operations in VFP to release resources, the situation remains unchanged, which really puzzles me.

 

[iswithzhz]

 

[dbMark]

This is not the same issue, but it reminded me of a problem I had years ago.

There was a perplexing issue over a decade ago I had with a VFP app running on a MS server. I never did find out why it wouldn't delete some temp tables and indexes. They would accumulate on the server until all storage was consumed. I did several rewrites of the tables, even testing whether the deletion worked and if not, then trying to delete again. Still didn't delete. Never figured out why. I ended up having to log onto the server and mass deleting the tables every few days before they accumulated enough to use up all the storage space.

 

[iswithzhz]

My problem is more complicated. Your logic is relatively simple. It's obvious that the temporary tables and indexes keep accumulating, and the key is to find the root cause. I spent the whole day yesterday on my problem and I think it might be solved. Why do I say "might"? Because I can't be certain myself. The situation is that I'm using a C++ application domain's IUnknown interface pointer for VFP to call a .NET COM component. I've taken a series of actions, such as releasing all managed objects, unloading the application domain, stopping the CLR runtime to release COM resources, and releasing COM resources. However, it seems that the memory occupied by VFP can't be fundamentally reclaimed.

 

[mJindrova]

VFP (3-9) has not many functions for releasing unused memory
SYS(1104) - free data cache for data area
API SetProcessWorkingSetSize(...) IN kernel32 - free unused memeory