Dear all,

In comobj.pp I'm getting sometimes a SIGSEGV in the following code:

    function TAutoObject.Invoke(DispID: LongInt; const iid: TGUID;
      LocaleID: longint; Flags: Word; var params; VarResult, ExcepInfo,
      ArgErr: pointer): HResult; stdcall;
	...
      begin
	...
          Result := TAutoObjectFactory(Factory).DispTypeInfo.Invoke(Pointer(
            PtrUint(Self) +

TAutoObjectFactory(Factory).DispIntfEntry^.IOffset), DispID, Flags, TDispParams(Params), PVariant(VarResult)^, PExcepInfo(ExcepInfo)^, PUINT(ArgErr)^);
...

	end;

The interface method called (ITypeInfo::Invoke) is defined in activex.pp as
     Function  Invoke(pvInstance: Pointer; memid: MEMBERID; wFlags: WORD;
VAR pDispParams: DISPPARAMS; OUT pVarResult: VARIANT; OUT pExcepInfo:
EXCEPINFO; OUT puArgErr: UINT):HResult;StdCall;

The problem is with the ExcepInfo parameter which is a record. ITypeInfo::Invoke can have a null pExcepInfo parameter and the PExcepInfo(ExcepInfo)^ cast causes a call to fpc_finalize with a null pointer.

Is there a way to avoid the finalisation of PExcepInfo(ExcepInfo)^ ? EXCEPINFO has a widestring member...

IMO the ITypeInfo::Invoke method should be changed to

     Function  Invoke(pvInstance: Pointer; memid: MEMBERID; wFlags: WORD;

VAR pDispParams: DISPPARAMS; pVarResult: PVARIANT; pExcepInfo: PEXCEPINFO; puArgErr: PUINT):HResult;StdCall;
but that requires changing all the code that calls this method. On the other hand I'm afraid that any code calling this method with the current definition will have potentially the same problem with the finalization of the EXCEPINFO record.

Ludo

Hi,

Funny, but I have also encountered the problem in this place yesterday :) But with PVariant(VarResult)^ in my case.
Yes, the declaration of ITypeInfo.Invoke() should be changed to eliminate unwanted compiler magic with managed types when a nil is passed.
I'll commit the required changes today or tomorrow.

Best Regards!

Yury Sidorov.

Yury Sidorov wrote

Funny, but I have also encountered the problem in this place yesterday :) But with PVariant(VarResult)^ in my case. Yes, the declaration of ITypeInfo.Invoke() should be changed to eliminate unwanted compiler magic with managed types when a nil is passed. I'll commit the required changes today or tomorrow.

Can't you add an overloaded version to avoid breaking backward compatibility? Or does this problem occur all the time, so that it's better to break compilation than have people hunt all over the source code to find all possible problem locations?

Jonas

Hello,

The declaration of ITypeInfo.Invoke() is broken now anyway. Some of out parametrs should accept nil values and it is not possible with the current declaration. I doubt that ITypeInfo.Invoke() is used directly by user code. Especially in this broken form.

Yury Sidorov,

I completely agree. According the MSDN the last 3 out parametes can be nil.

Attached is the patch that works for me. I'm writing a fpc COM server called with late binding from PHP.

Ludo

In our previous episode, Jonas Maebe said:

Afaik there is no overloading in interfaces?

Or does this problem occur all the time, so that it's better to break compilation than have people hunt all over the source code to find all possible problem locations?

I also don't think this is used that much. Afaik 2.6.0 is the first release with most of the autoobject and activex stuff merged back.

So if there is a change needed, better do it asap.

Committed in r22638. Thanks.