std::mutex->std::recursive_mutex in SvtUserOptions
Since commit
ac511d90cdf9d28eb8809c30be9fa08b42ea0bd3
Author Noel Grandin <noelgrandin@gmail.com>
Date Thu Dec 23 19:42:19 2021 +0200
osl::Mutex->std::mutex in SvtUserOptions
non-recursive std::mutex is used. However, it looks like recursive
locking is possible here, as shows the debugging that I made
during the work on https://gerrit.libreoffice.org/c/core/+/134251.
The call stack looks like this:
utllo.dll!SvtUserOptions::GetToken(UserOptToken nToken) Line 318
utllo.dll!SvtUserOptions::GetLastName() Line 294
sclo.dll!ScChangeTrack::ConfigurationChanged(utl::ConfigurationBroadcaster * __formal, ConfigurationHints __formal) Line 2166
utllo.dll!utl::ConfigurationBroadcaster::NotifyListeners(ConfigurationHints nHint) Line 85
utllo.dll!utl::detail::Options::ConfigurationChanged(utl::ConfigurationBroadcaster * __formal, ConfigurationHints nHint) Line 112
utllo.dll!utl::ConfigurationBroadcaster::NotifyListeners(ConfigurationHints nHint) Line 85
utllo.dll!SvtUserOptions::Impl::Notify() Line 251
utllo.dll!SvtUserOptions::ChangeListener::changesOccurred(const com::sun::star::util::ChangesEvent & rEvent) Line 116
configmgrlo.dll!configmgr::Broadcaster::send() Line 168
configmgrlo.dll!configmgr::Access::setPropertyValue(const rtl::OUString & aPropertyName, const com::sun::star::uno::Any & aValue) Line 714
utllo.dll!SvtUserOptions::Impl::SetValue_Impl<rtl::OUString>(UserOptToken nToken, const rtl::OUString & sToken) Line 183
utllo.dll!SvtUserOptions::Impl::SetToken(UserOptToken nToken, const rtl::OUString & sToken) Line 200
utllo.dll!SvtUserOptions::SetToken(UserOptToken nToken, const rtl::OUString & rNewToken) Line 325
test_sc_subsequent_export_test.dll!ScExportTest::testTrackChangesSimpleXLSX() Line 3072
...
So getting the token may happen during notification of the listeners
after setting the token, in the same thread. So let's use recursive
mutex.
Change-Id: I9be82f307a9948bcbc76d7d90632a0307c5dc4f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134190
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>