Reimplement OleComponentNative_Impl to use IGlobalInterfaceTable

... to make sure that object methods are called in correct apartment

The user-visible problem was, that running a Java code that connects
to LibreOffice, and opening a document with an embedded OLE object
(it was Word object in a specific case, which needs activation at
opening stage, because these objects have OLEMISC_RECOMPOSEONRESIZE
flag), using loadComponentFromURL with "OnMainThread" set to true,
then closing the document, resulted in a hang after several hundreds
iterations. This was caused by Word process, that was started in
background to serve the COM calls, wasn't closed properly, and kept
all the objects in memory, until OOM.

The reason why it wasn't closed was failed call to IOleObject::Close
in OleComponent::CloseObject, which returned RPC_E_WRONG_THREAD,
because the activation of the OLE object happened in the main thread
(because of "OnMainThread"), which is STA, but closing happened in
the handler thread (belonging to MTA).

Similar problems previously were addressed in commits
2dc3a6c273cb82506842864481d78df7294debbf (framework: allow loading a
component on the main thread, 2018-12-20),
6002014ce0a5c9cea22c14b2437b7a508b2c72cb (framework: allow loading a
component on the main thread, using XDesktop, 2021-04-28),
d5cd62164d32273a25913c93aa04be9f7f3a4073 (embeddedobj: handle getting
the visible area on a thread, 2021-05-07).
These changes tried different workarounds for the same problem, when
a COM object instantiated in one apartment is later manipulated from
another, which fails. First two handled the case when the document
is loaded from a non-UI thread, and then manipulated with the UI; to
handle that, they introduced flags that delegated opening the file
to the main (UI) thread. The last change tried to handle the reverse
problem of the OLE object instantiated in the main thread was saved
in a handler thread, which again failed; the workaround was, again,
to try to delegate the second attempt to the main thread.

But basically all methods can fail in such circumstations, as shown
in this problem's case. The "OnMainThread" flag must be passed to
fileopen functions explicitly. Also, the workarounds only work by
passing everything to STA, and don't target a case when the calls
must be passed from STA to MTA.

Since Windows 2000, there is IGlobalInterfaceTable, which goal is
to solve this problem. It allows to use an intermediate object,
which can transparently delegate all calls to the correct thread.

This change re-implements how OLE objects are referenced from
OleComponentNative_Impl, using the said IGlobalInterfaceTable.
This should hopefully obsolete the previous workarounds, which
nevertheless are kept for now.

Change-Id: Ia1c590e547ed24a2c7389283aed6cc3d8ea024b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164457
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

0 files changed, 0 insertions, 0 deletions