Regression from commit 2dc3a6c273
(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
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Xisco Fauli