Alaska Software Inc. - Hotfix 16 question
Username: Password:
AuthorTopic: Hotfix 16 question
Roger DonnayHotfix 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 ZieglerRe: 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