Lock SolarMutex around fmFormShell::DetermineForms calls

At least in JunitTest_forms_unoapi there are calls via URP of

 SfxShell::UIFeatureChanged
 FmFormShell::DetermineForms
 FmXFormShell::elementInserted
 cppu::OInterfaceContainerHelper::NotifySingleListener<...>::operator()
 cppu::OInterfaceContainerHelper::forEach<...>
 cppu::OInterfaceContainerHelper::notifyEach<...>
 frm::OInterfaceContainer::implInsert
 frm::OInterfaceContainer::insertByName
 frm::OFormsCollection::insertByName
 ...

where SfxShell::UIFeatureChanged does an svtools::AsynchronLink::Call, and there
are notorious crashes during JunitTest_forms_unoapi in

 vcl::Window::ImplRemoveDel
 Application::RemoveUserEvent
 svtools::AsynchronLink::~AsynchronLink
 SfxShell_Impl::~SfxShell_Impl
 SfxShell::~SfxShell
 FmFomrShell::~FmFormShell
 ...

and the naive hope is that the former's unlocked operations cause some
corruption that make the latter operate on a dangling AsynchronLink::_nEventId.

(As always, the question is at which level to lock the solar mutex;
frm::OFormsCollection et al appear to be properly mutex'ed, FmXFormShell appears
to be virtually un-mutex'ed, except for some smelly m_aInvalidationSafety and
m_aAsyncSafety, and FmFormShell and SfxShell appear to run under the assumption
that the solar mutex is always locked.  So stick the guards into FmXFormShell---
which is the only place calling DetermineForms---under the assumption that that
is the most likely place needing general mutex clean-up in the future, and thus
bears the highest chance the potentially becoming redundant guards will be
noticed again.)

Change-Id: Iad0f4bd9af2bf62330e26ac50edd170f470e79c4

0 files changed, 0 insertions, 0 deletions