#294 oleObject = OleInitialize needs to be called for each thread

Classes (154)

Mark requested I open a problem report on this issue.

I am getting a NIL object returned from .OLEObject most/some of the time when I try to create an access from a concurrent method.

I am running on Windows XP Pro SP2 with an AMD Athlon XP 2400+ processor. The OS has all but the most recent (last month) updates on it. My ooREXX is Version 3.2.0.

I don't have access to my SourceForge account for now, trying to reclaim it. You can contact me at bobjewett@rr3weather.com

Below is a sample ooREXX program that hopefully shows the problem. The problem for me is about 60% of the time on my systems. If you remove the 1st .OLEobject~getobject statement or the "reply" statement, it works 100% of the time.

Bob Jewett
OS/2 User!

---------- CLIP --------
/ The next stmt needed to setup failure /


::REQUIRES "winsystm.cls"

::CLASS "thread"

::METHOD "init"
reply -- If I remove this statement, it works!
activeX = .OLEObject~getobject("winmgmts:\.\root\cimv2")

say activeX -- Why does this say "The NIL object" most of the time?

Bob Jewett,
OS/2 User!


  • Mark Miesfeld

    Mark Miesfeld - 2008-09-02

    Logged In: YES
    Originator: NO

    The problem demonstrated by the example is inherent in the way OLEObject is designed.

    The COM library needs to be initialized for each apartment that calls COM functions. OLEObject only initializes the COM library on the first apartment that an OLEObject is instantiated in.

    In the example program, the COM library is initialized during the fist invocation of getObject(). In the init() method of the 'Thread' class, when the early reply is used, the second invocation of getObject() runs in a different apartment. Since the COM library is not initialized for that apartment, the call to BindToObject() fails. (Actually it might be the call to MkParseDisplayName() that fails. It was a couple of weeks ago that I looked at this.)

    If I put in some temporary code to initialize the COM library in the second apartment, then everything works as expected.

    Since we already have a lot to do to get the next release out the door, I don't intend to make any changes here for the next release and this will probably have to wait until later. Just wanted to jot down some notes so that I remember what I did on this and let Bob know that it is not forgotten.

  • Bob

    Bob - 2008-10-08


    Thanks for the followup.
    Would it be possible to fix this in 4.0.1?

    Bob Jewett
    OS/2 User

  • Mark Miesfeld

    Mark Miesfeld - 2011-01-14

    This actually is a serious flaw in OleObject.

    Now that ooDialog can invoke event handlers directly from the Windows message loop, I'm seeing this problem more and more.

    Plus, I beleive we have a memory leak in the current implementation. OleInitialize() is called on the first thread that a COM object is created in. OleUnitialize is called when the last COM object is releaed. This usually happens in the uninit method, and it looks like this is never the same thread that OleInitialize is called on.

    I can't find any definite statement from Microsoft that the two have to be called on the same thread. But, Microsoft does emphasis that the calls have to be paired.

    To fix this, we need to call OleInitialize for each thread a COM object is created on and need to call OleUnitialize once for each call to OleInitalize.

  • Mark Miesfeld

    Mark Miesfeld - 2012-02-09

    I'm going to move this to a Request For Enhancement. Although it is a flaw in the design, it is actually working as designed.

    I realize that is a somewhat semantic decision, but it's doubtful to me at this point that anyone other than myself is likely to work on this.



Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks