Rob Shearman wrote:
Does this happen with only builtin oleaut32?
I'm not sure, I didn't try mixing native/builtins for this problem.
If so, it should be fixed so that it doesn't cause an infinite loop. I don't think standard marshaled proxies should cause infinite loops (if I remember the test cases we have correctly).
Yes, I also have a vague feeling that it may be covering up for an issue elsewhere, but can't quite place my finger on what. The problem was quite subtle and confusing (as everything in DCOM is <sigh>)
InstallShield gets a TLB proxy
xCall, IUnknown::QueryInterface -> rpc to stub -> IRemUnknown::RemQueryInterface marshals result
tmarshal.c:_unmarshal_interface called on the result of the QI
CoUnmarshalInterface( ... results of QI ... )
IMarshal::UnmarshalInterface sets up the TLBProxy IUnknown::QueryInterface on the TLBProxy object xCall, IUnknown::QueryInterface -> rpc to stub -> [infinite loop]
I have a feeling the QI in CoUnmarshalInterface should be a no-op because the typelib proxies should aggregate the proxy manager, which would optimize out a QI for an already unmarshalled interface.
So possibly the real issue is that we never made the tmarshaller aggregate the proxy manager. I don't recall if you did that or not, I know I didn't.
However, this patch should go in as it is a good optimisation.
Right. It also unblocks InstallShield for the time being, letting us get back to the stage where it needs RPC re-entrancy.
thanks -mike