Regression from commit 2dc3a6c273cb82506842864481d78df7294debbf (framework: allow loading a component on the main thread, 2018-12-19), which was a forward-port from a 5.4-based vendor branch, where this was (it turns out) just working by accident, but never on master.
It can happen that loadComponentFromURL() is invoked on a thread, which does not own the solar mutex. Then once
vcl::SolarThreadExecutor::execute() is called, it'll try to release the solar mutex. But SolarMutexReleaser is unsafe: it'll release the mutex even if it is owned by an other thread.
To make this a bit more safer, it'll abort in comphelper::SolarMutex::doRelease(), in case the current thread doesn't have the mutex already.
Fix the problem by taking the solar mutex in loadComponentFromURL(): this is meant to cause no performance problems, since the actual importers typically start with taking the solar mutex anyway. Taking it earlier would be problematic, since this can be invoked by UNO clients directly. Taking it later in vcl/ would be also unusual: typically vcl just asserts that the solar mutex is locked, doesn't take it itself.
Change-Id: I752006a91f16a02254d1b5ac6301100ab282630b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103264
07b399eb91fb framework: lock the solar mutex in loadComponentFromURL() with OnMainThread
framework/CppunitTest_framework_services.mk | 40 +++++++++
framework/Module_framework.mk | 7 ++
framework/qa/cppunit/services.cxx | 133 ++++++++++++++++++++++++++++
framework/source/services/frame.cxx | 7 ++
4 files changed, 187 insertions(+)