COM and threads

Fabian Cenedese Cenedese at
Tue Nov 26 07:27:18 CST 2002


There were some postings recently about CoInitialize and theads:

"Sort of, the problem is that Wine doesn't support apartments yet, so it
doesn't try to keep track of the threads that has called CoInitialize."

I now have a problem that goes maybe in the same direction. I have an
ocx which is again embedded in another ocx. In the wrapper are two
threads (Msg and worker). I now get an error if the second thread tries
to call a function from the embedded ocx. In the wine log I can find only
one call to CoInitialize.

This is right before the call of the second ocx:

0811c6d0:Call ole32.CoGetMalloc(00000001,4211275c) ret=65352782
0811c6d0:Ret  ole32.CoGetMalloc() retval=00000000 ret=65352782
trace:ole:IMalloc_fnAlloc (292)
trace:ole:IMallocSpy_fnPreAlloc (0x40a00944)->(292)
trace:heap:RtlAllocateHeap (0x40380000,00000002,00000128): returning 403d5308
trace:ole:IMallocSpy_fnPostAlloc (0x40a00944)->(0x403d5308)
trace:ole:IMalloc_fnAlloc --(0x403d5308)
0811c6d0:Call kernel32.InterlockedIncrement(403c9ad4) ret=65352c07
0811c6d0:Ret  kernel32.InterlockedIncrement() retval=00000002 ret=65352c07
0811c6d0:Ret  ole32.CoCreateInstanceEx() retval=80070057 ret=65352c8d
0811c6d0:Call ole32.CoSetState(653c3f80) ret=653527ec
fixme:ole:CoSetState (0x653c3f80),stub!
trace:ole:CoSetState -- release 0x653c3f80 now
0811c6d0:Call kernel32.InterlockedDecrement(403c9ad4) ret=65356c7e
0811c6d0:Ret  kernel32.InterlockedDecrement() retval=00000001 ret=65356c7e

some window, gdi32 and heap functions

08119650:Call gdi32.CreateRectRgnIndirect(406e26bc) ret=4083c19e
trace:heap:RtlAllocateHeap (0x40380000,00000002,00000020): returning 403d50c8
trace:heap:RtlAllocateHeap (0x40380000,00000002,00000020): returning 403d5050
08119650:Ret  gdi32.CreateRectRgnIndirect() retval=00001842 ret=4083c19e
08119650:Call gdi32.CombineRgn(0000184e,0000184e,00001842,00000001) 
trace:heap:RtlAllocateHeap (0x40380000,00000002,00000020): returning 403d4ea0
trace:ole:IMalloc_fnFree (0x403d5308)
trace:ole:IMallocSpy_fnPreFree (0x40a00944)->(0x403d5308 1)
trace:heap:RtlFreeHeap (0x40380000,00000002,403d5308): returning TRUE
trace:ole:IMallocSpy_fnPostFree (0x40a00944)->(1)
0811c6d0:Ret  ole32.CoSetState() retval=00000000 ret=653527ec
trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x65341543
trace:seh:EXC_RtlRaiseException  info[0]=00000000
trace:seh:EXC_RtlRaiseException  info[1]=00000010

The exception is right after CoSetState even if it says above that this is only
a stub. It's that bad that I don't even have a call stack anymore.

The function in the embedded ocx is never reached. But I can use the ocx
in a simple VB proggy so I'd say registration is ok. I'm quite sure the problem
lies in the two threads because it works better when I use only one thread
in the wrapper ocx. Can somebody confirm this? Is there a workaround for
this until wine supports COM with several threads?


bye   Fabi

More information about the wine-devel mailing list