SolarMutex assert on adding an extension ?

[Michael Stahl]

On 06/10/14 22:10, Caolán McNamara wrote:
> If I try and install the extension from
> https://bugs.freedesktop.org/show_bug.cgi?id=46447#c151
> in master I get...
> 
> warn:vcl:29279:9:vcl/generic/app/geninst.cxx:116: CheckYieldMutex: 0!=9
> 
> which is
> SalYieldMutex* pYieldMutex = mpSalYieldMutex;
> if ( pYieldMutex->GetThreadId() != osl::Thread::getCurrentIdentifier() )
>     return false;
> 
> causes this assert to trigger
> assert(ImplGetSVData()->mpDefInst->CheckYieldMutex());                                                                           
> 
> from DBG_TESTSOLARMUTEX(); in svl/source/notify/SfxBroadcaster.cxx's
> SfxBroadcaster::AddListener
> 
> all the way from ExtensionCmdQueue::Thread::execute where everything is
> happening in a thread to add an extension and so (because this is a
> basic extension) BasicManagerRepository::getApplicationBasicManager is
> called from the thread.
> 
> What should we do here ?

despair about the haphazard and inconsistent locking in basic, i guess.

after looking at it for a bit i don't see any obvious justification for
the SolarMutex not being locked around accesses of core BASIC objects
like SbModule etc, i.e. there is no other mutex that is consistently used.

so i'd think that using SolarMutex for the purpose is probably the least
bad way forward, and have converted some of the existing locking in
basic's UNO objects to SolarMutex on master, which apparently fixes the
extension installation.