forked from amazingfate/loongoffice
7d9ac36503
When destroying the static vcl::CommandInfoProvider aProvider from vcl::CommandInfoProvider::Instance (vcl/source/helper/commandinfoprovider.cxx) during exit, it releases its mxCachedGlobalAcceleratorConfiguration reference on GlobalAcceleratorConfiguration (framework/source/accelerators/globalacceleratorconfiguration.cxx), which may get destroyed, whose base class framework::XCUBasedAcceleratorConfiguration (framework/source/inc/accelerators/acceleratorconfiguration.hxx) has a salhelper::SingletonRef<framework::KeyMapping> member, whose destructor (include/salhelper/singletonref.hxx) uses salhelper::SingletonRef<framework::KeyMapping>::SingletonLockInit::operator ()'s static osl::Mutex aInstance. If, during construction, the instantiation of salhelper::SingletonRef<framework::KeyMapping>::SingletonLockInit::operator ()'s static osl::Mutex aInstance finishes before the instantiation of vcl::CommandInfoProvider::Instance's static vcl::CommandInfoProvider aProvider, the corresponding atexit cleanup actions will be recorded in the right order, causing the above chain of calls to find the static Mutex still alive when used from within the static CommandInfoProvider's destruction. However, vcl::CommandInfoProvider's mxCachedGlobalAcceleratorConfiguration is only set to css::ui::GlobalAcceleratorConfiguration::create in vcl::CommandInfoProvider::GetGlobalAcceleratorConfiguration, so the instantiation of the static Mutex instance can finish after the instantiation of the static CommandInfoProvider instance, recording the atexit cleanup actions in the wrong order, causing the static Mutex to be used after destruction. This occasionally caused PythonTest_sfx2_python to hang during exit for me on Linux, where trying to lock a destroyed pthread mutex can apparently deadlock. rtl::Static does away with the need to do anything in the destructor, at the expense of always keeping the instance alive until exit (and not being able to recreate an already destroyed instance during exit, but code that would require that behavior would probably already be broken to begin with), so the order of creation of the CommandInfoProvider and GlobalAcceleratorConfiguration instances becomes less of a concern. Change-Id: Id6e3860ad9e5b7045980a0b9bf9eaef2e24129bb