Is C++ COM interface for imported "RegExp.tlb" implicitly sharing memory between processes?

Question

Good time. Sorry if my question is strange, but I'm new in things I've faced.

My case is in following, I'm using VB RegExp in C++ through COM as following:

#import "RegExp.tlb" no_namespace
...
void DoSomething() {
    ...
    static IRegExpPtr regExp( __uuidof(RegExp) );    
    regExp->Pattern = A2BSTR(m_szStrReg); // read on dll load from the file     
    if ( regExp->Test(someString) ) {
        IMatchCollectionPtr matches = regExp->Execute(someString);
        // my staff here
        ...
    }
    ...
}

My questions are:

1. Am I doing everything right? (p.s. I know about CoInit and CoUninit but the question is not about them).

2. Is regExp process safe? The reason I ask this is cause I have several instances of my class with DoSomething() calling it for many times. And I have CRASH in regExp internals. Caused by heap corruption/invalid memory access randomly in different calls of regExp methods with different args.

I've checked the regExp pointer value, regExp->Pattern.GetAddress() and so on. And they are different in different processes. But when I've added named Mutex and wrapped DoSomething() with it adding interprocess synchronization - the CRASH DISSAPPEARED. That's why I am asking if regExp has something implicitly shared between processes?

Answer 1

Your code is dealing with COM interface pointer living in current apartment. You are aware about COM initialization already, so current apartment means current thread if you are in STA in particular. You are guaranteed that methods of the interface pointer are callable but the back end of this interface pointer might vary: it can be implementation directly, or it can be a helper object (proxy) which transfers the call into the apartment where the actual object resides. The latter in particular might be in another process.

This is all thread safe and "process safe". The parameters are taken with the call to the actual object and then transferred back. Caller don't have to care whether it's dealing with real object or a proxy, and the callee too does not need to know whether it's called by actual caller or a helper stub.

Having said that, the code snippet above is good. The crash you were having has to have another cause.