Stephan Bergmann
ef53355355
<https://gerrit.libreoffice.org/c/core/+/144139> "New loplugin:unocast" had argued that uses of dynamic_cast from a UNO interface type are broken in general (because if the source object is a proxy from the C*+ UNO bridge, its vtable's RTTI slot will normally not be set up, which can cause a crash), and should be replaced with uses of XUnoTunnel. Which the various recent "loplugin:unocast (...)" commits started to do. However, it became clear that that is not the most ideal way forward: For one, getting more and more implementations of XUnoTunnel::getSomething into existing class hierarchies is error prone, as each such implementation must manually delegate to all its base class implementations. For another, uses of comphelper::getFromUnoTunnel (which often needs to do a queryInterface to XUnoTunnel first) are easily more expensive than uses of dynamic_cast. Thanks to Noel, the insight here is that for the use case of a dynamic_cast from a UNO interface type to a local C++ class type, and if the source object is a proxy, it is sufficient that the dynamic_cast will not crash. It will necessarily always return null (as the proxy will never be the implementation of a local C++ class type), so it is sufficient to fill the RTTI slots of the proxies' vtables with dummy values. That avoids having to set up proper RTTI for those potentially multiple-inheritance proxy types. (And with this in place, all those recent "loplugin:unocast (...)" commits can be reverted again in a next step.) I verified the changes for the gcc3_linux_aarch64 (on macOS), gcc3_linux_intel, gcc3_linux_x86-64, gcc3_macosx_x86-64, msvc_win32_intel, and msvc_win32_x86-64 bridges. The changes for all the other bridges were done blindly. (For gcc3_linux_x86-64, which already conditionally supported proper RTTI for UBSan, setting the offset-to-top slot to non-zero had to be made conditional too, as the dummy ProxyRtti will always pretend to be a full class rather than a potential base class that could have a non-zero offset-to-top value. For msvc_win32_*, it turned out that the existing code to set up dummy XInterface RTTI (which was there for reasons lost to history) was broken.) Change-Id: Iec4b8067d26b14b6fb02c2fdd15e1eee20919590 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145038 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Testing Tools
How to Check Compatibility Between Compilers
Since the interfaces used in the cpp bridgetest are not changed often
one can just build the cppobj.uno.dll and the constructors.uno.dll
(testtools/source/bridgetest) in an
old environment and then use them in the new environment. That is the files
are copied into the testtools/wntmsciXX.pro folder which corresponds to the
new environment.
On Windows this test will typically fail because the tests use the
cppu::getCaughtException function, which only works when all libs are build
using the same runtime.
This part of the test can switched off. To do this go into the
testtools/source/bridgetest folder and call
dmake compcheck=1
This will add a new compiler define (-DCOMPCHECK) and will be used in the
bridgetest.cxx to switch off the code which uses the getCaughtException function.
However, there is still a test which causes the test component to throw
and IllegalArgumentException. This still works.
Using source / bridgetest for Stress Testing
Start a modified bridgetest_server (with the final --singleaccept argument
removed from the uno executable call) or a modified bridgetest_javaserver (with
the final singleaccept argument replaced with multi in the java executable
call), then start a modified bridgetest_client (with a final stress argument
added to the uno executable call). The client will continuously establish
connections to the server which are immediately destroyed again. The test will
run forever, unless an error occurs.