Author | Topic: Hotfix 16 question | |
---|---|---|
Roger Donnay | Hotfix 16 question on Sun, 04 May 2008 11:08:10 -0600 Does anyone know why Hotfix 16 would fix a memory problem with threads when the only DLL in the hotfix is ASCOM10C.DLL? This is an ActiveX DLL. I'm suprised that the thread management system would be in this DLL. Or do I not understand the PDR? Is is possible that the memory leak only occurred when instantiating an ActiveX object? I'm asking this question because I have a customer who is experiencing a serious memory leak but we haven't yet nailed it down to where it is happening. | |
Hannes Ziegler | Re: Hotfix 16 question on Mon, 05 May 2008 02:07:09 +0200 Roger, > I'm asking this question because I have a customer who is experiencing a > serious memory leak but we haven't yet nailed it down to where it is > happening. I'm not sure how ASCOM*.DLL treats multi-threading issues with ActiveX. The Windows platform SDK offers different approaches for COM/ActiveX usage with threads. You might want to look into http://support.microsoft.com/kb/206076/en-us/ and download http://download.microsoft.com/download/vc60pro/info2/1/win98/en-us/marshal.exe to get a glimpse of what it means to exchange COM/ActiveX data between threads on the OS level, not to speak of exchanging Windows messages between a window handle in the Xbase++ GUI thread and an ActiveX control's window handle created in the main thread. Andreas, Steffen and Till must have good reasons for offering :useGuiThread := .F.|.T. with ActiveX controls (which is neither documented nor explained, BTW). <!-- Thomas Braun: please add a new item to your check list: HZ has failed to elaborate the ActiveX/thread issues in the Xbase++ docs in depth -->. I can imagine that all "pre-hotfix #16" releases "forget" to release memory handles in ActiveX usage when a message is cross posted between the main thread and the GUI thread, or when an ActiveX object is not :destroy()ed before a thread ends. This is certainly an issue of ASCOM*.DLL only. I would try two scenarios to isolate your customer's memory leak: 1) Cross posting events to ActiveX controls between different threads (running their own event loops) 2) Creating/Destroying AxtiveX controls in threads that are started/killed frequently FWIW, a final answer is due to Alaska's support. I'd be interested in a final answer as well. HTH, -- Hannes |