framework: lock the solar mutex in loadComponentFromURL() with OnMainThread
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
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
2020-09-24 06:58:44 -05:00
|
|
|
# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*-
|
|
|
|
|
#
|
|
|
|
|
# This file is part of the LibreOffice project.
|
|
|
|
|
#
|
|
|
|
|
# This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
|
# License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
|
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_CppunitTest,framework_services))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_add_exception_objects,framework_services, \
|
|
|
|
|
framework/qa/cppunit/services \
|
|
|
|
|
))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_sdk_api,framework_services))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_libraries,framework_services, \
|
|
|
|
|
comphelper \
|
|
|
|
|
cppu \
|
|
|
|
|
cppuhelper \
|
|
|
|
|
sal \
|
|
|
|
|
salhelper \
|
2022-11-22 04:07:23 -06:00
|
|
|
subsequenttest \
|
framework: lock the solar mutex in loadComponentFromURL() with OnMainThread
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
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
2020-09-24 06:58:44 -05:00
|
|
|
test \
|
|
|
|
|
unotest \
|
2022-11-22 04:07:23 -06:00
|
|
|
utl \
|
|
|
|
|
tl \
|
framework: lock the solar mutex in loadComponentFromURL() with OnMainThread
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
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
2020-09-24 06:58:44 -05:00
|
|
|
vcl \
|
|
|
|
|
))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_external,framework_services,boost_headers))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_sdk_api,framework_services))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_ure,framework_services))
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_vcl,framework_services))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_rdb,framework_services,services))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_configuration,framework_services))
|
|
|
|
|
|
|
|
|
|
# vim: set noet sw=4 ts=4:
|
