Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
Hi Stephan
Thank you for your effort to review my posts and give suggestions. Please
see my answers below.
Stephan Bergmann-2 wrote
>
> So the situation is as follows: When your notifyTermination() listener
> is called (which apparently happens with the SolarMutex being locked),
> you need to synchronously terminate and join your worker thread. But at
> that time your worker thread happens to be blocked waiting for the
> SolarMutex, at some stack frame nested in a call to some modified()
> (which is part of your code). Right? (Can you make available the
> source code of your extension?)
>
> I still see no true fix short of having the notifyTermination listeners
> being fired without SolarMutex locked.
>
There is a little difference: I used both queryTermination() and
notifyTermination(). Modified() may be blocked by queryTermination(), not
notifyTermination(). It happens by chance, not always. Then I do send a stop
message to the worker thread at notifyTermination(). Please see my
explanation in the code.
void SAL_CALL BLP_VolatileResult::newValue() // Here is the place
calling
modified()
{
ResultEvent aEvent = getResult();
for(XResultListenerVector::iterator iter = aListeners.begin();
iter !=
aListeners.end(); ++iter)
{
try
{
if (rtSessionStatus == RUNNING)
//rtSessionStaus is a global variable
{
(*iter)->modified(aEvent);
}
}
catch (::com::sun::star::uno::Exception &)
{
iter = aListeners.erase(iter);
}
}
}
// If modified() is called by the worker thread at the same time, the worker
thread is blocked forever; If not, everything goes through.
void SAL_CALL CalcTerminateListener::queryTermination(const
::com::sun::star::lang::EventObject& aEvent)
throw( ::com::sun::star::frame::TerminationVetoException,
::com::sun::star::uno::RuntimeException )
{
if (blp_conn->isRun()) //check if rtSessionStatus == RUNNING
{
blp_conn->prepareClose(); //set up rtSessionStatus = STOPPING
throw ::com::sun::star::frame::TerminationVetoException();
}
}
void SAL_CALL CalcTerminateListener::notifyTermination(const
::com::sun::star::lang::EventObject& aEvent)
throw( ::com::sun::star::uno::RuntimeException )
{
blp_conn->close(); //will send a stop message to the worker session
which
connects to a outside server.
//it returns immediately.
If no block, the worker session will be ready for deletion later.
//If the worker session is
blocked by queryTermination() at modified(),
//it will wait forever,
deadlock. Maybe you can say it prepare to join and terminate the
//worker thread
synchronously.
}
blp_conn::~blp_conn()
{
if (d_session)
deleting d_session; //d_session is in charge of the worker thread. If
the worker thread is blocked at
//queryTermination() with
modified(), deadlock happens. Maybe you can say this step tries
//to join and terminate the
worker thread synchronously.
}
> So, you manually need to click the 'X' to close the LibreOffice window
> twice?
>
> And where do you call the code to terminate and join your worker thread
> now? (Or do you not call such code at all, and things appear to work by
> chance, due to changes in timing?)
>
> Stephan
>
Yes, I do it twice. The first time, it calls queryTermination(), sets up
rtSessionStatus, and then is vetoed. Then I click x again. It calls
queryTermination, then notifyTermination() where I try to stop the worker
thread, and other destruction procedures where I try to join and terminate
the worker thread.
I am suggested to create a new thread at queryTermination() along with
changing rtSessionStatus. This new thread will wait for a while and call
XDesktop.terminate(), just a simulation of the second click. Is it possible
to create such a new thread within LibreOffice extension?
Thank you.
Wendi
--
View this message in context:
http://nabble.documentfoundation.org/Solarmutex-Deadlock-when-Closing-Calc-which-contains-functions-with-XVolatileResult-return-values-tp3998056p4001815.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
On 08/15/2012 04:58 PM, anwen wrote: A brief summary of this discussion: My purpose is to develop a Calc extension based on LibreOffice environment. As an extension, it registers itself as a UNO component and provides some add-in functions which retrieve streaming data. This extension object builds connections via worker threads to an outside streaming data server. Everything runs well until I terminate the LibreOffice with x click: Soffice.bin/Soffice.exe are still alive after the termination process is completed and all the documents are closed. It happens when the worker threads try to update the spreadsheet using modified() function and the termination process tries to stop the worker threads. SolarMutex may be the reason of this issue. To solve the issue, I implemented two interfaces: XTerminationListener and XEventListener. The former listens to desktop.termination. The latter listens to document events. From my observation, the worker thread could be blocked within modified() forever by queryTermination() and notifyTermination(). It could also be blocked forever by some documents events, like OnPrepareViewClosing, OnPrepareUnload, OnViewClosed, OnUnload, OnUnfocus, and OnCloseApp. Interestingly, I observed that the worker thread could resume running when seeing OnModeChanged event. So the situation is as follows: When your notifyTermination() listener is called (which apparently happens with the SolarMutex being locked), you need to synchronously terminate and join your worker thread. But at that time your worker thread happens to be blocked waiting for the SolarMutex, at some stack frame nested in a call to some modified() (which is part of your code). Right? (Can you make available the source code of your extension?) I still see no true fix short of having the notifyTermination listeners being fired without SolarMutex locked. Currently, my workaround with the SolarMutex issue is double termination 'x'' clicks: first termination is vetoed in queryTermination() where I setup status change to avoid modified(). Then the second termination will kill all the threads and the LibreOffice process. Right now, I did double terminations manually. I am wondering if I could manipulate OnModeChanged events which may solve the issue too. Although the spreadsheet shows dynamic data with XVolatileResult return type, it does not popup save dialogue if I open an existing calc file. So, you manually need to click the 'X' to close the LibreOffice window twice? And where do you call the code to terminate and join your worker thread now? (Or do you not call such code at all, and things appear to work by chance, due to changes in timing?) Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
ronous" nature > of the notification that i bet extensions depend upon is left as an > exercise for the reader. > > [1] in fact (to add insult to injury) SfxBaseModel has a mutex member > that is used exactly once, to initialize its > cppu::OMultiTypeInterfaceContainerHelper member. > > _______________ > LibreOffice mailing list > LibreOffice@.freedesktop > http://lists.freedesktop.org/mailman/listinfo/libreoffice > Thank you -- View this message in context: http://nabble.documentfoundation.org/Solarmutex-Deadlock-when-Closing-Calc-which-contains-functions-with-XVolatileResult-return-values-tp3998056p4001524.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
On 14/08/12 16:30, Stephan Bergmann wrote: > On 08/14/2012 03:20 PM, anwen wrote: >> In addition, from the link >> (http://www.openoffice.org/api/docs/common/ref/com/sun/star/sdb/OfficeDatabaseDocument.html), >> I saw that both "OnPrepareUnload" and "OnUnload" events are synchronously >> broadcaster. Does it mean SolarMutex protection again? I really hope it does >> not. > > I'm not sure what that "broadcasted synchronously" column there is > supposed to mean. i guess it means that the event is broadcast immediately when it occurs, blocking the event source until it is handled. asynchronous document events (in SFX based apps) seem to be delayed via SfxEventAsyncer_Impl, which creates a VCL timer that times out immediately. > In general, (UNO) listener notifications must happen > with no mutices locked. So I would hope for "it does not" too... so much for the theory; in practice SFX pre-dates UNO and was possibly not designed with threading in mind, thus this is not actually what happens; it appears that the OnUnload event originates in SfxBaseController::dispose() (which of course locks SolarMutex thoughout). as SFX_APP()->NotifyEvent( SfxEventHint(SFX_EVENT_CLOSEDOC and then is transmitted via SfxBroadcaster interface to SfxBaseModel::Notify, then to SfxBaseModel::postEvent_Impl which uses the cppu::OMultiTypeInterfaceContainerHelper member [1] of IMPL_SfxBaseModel_DataContainer to send the event out via UNO interface XDocumentEventListener::documentEventOccured. then the SfxGlobalEvents_Impl (GlobalEventBroadcaster) gets it and just forwards it to the registered listeners. (i get the idea that the GlobalEventBroadcaster exists mainly to allow for listening for events at documents that are currently being loaded or created, so the client does not have a reference to the document yet) figuring out how to fix all that without losing the "synchronous" nature of the notification that i bet extensions depend upon is left as an exercise for the reader. [1] in fact (to add insult to injury) SfxBaseModel has a mutex member that is used exactly once, to initialize its cppu::OMultiTypeInterfaceContainerHelper member. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
On 08/14/2012 03:20 PM, anwen wrote: In addition, from the link (http://www.openoffice.org/api/docs/common/ref/com/sun/star/sdb/OfficeDatabaseDocument.html), I saw that both "OnPrepareUnload" and "OnUnload" events are synchronously broadcaster. Does it mean SolarMutex protection again? I really hope it does not. I'm not sure what that "broadcasted synchronously" column there is supposed to mean. In general, (UNO) listener notifications must happen with no mutices locked. So I would hope for "it does not" too... Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
Stephan Bergmann-2 wrote
>
> On 08/14/2012 12:35 AM, anwen wrote:
>> I implemented the above code with c++ . However, it did not work.
>> Anything
>> wrong with the following code:
>> m_xCC is a given Reference
>>
>> Reference
>> xBrd(m_xCC->getServiceManager()->createInstanceWithContext(OUString(RTL_CONSTASCII_USTRINGPARAM("com.sun.star.frame.GlobalEventbroadcaster")),
>
> it's "GlobalEventBroadcaster" (with a capital "B")
>
> Stephan
>
>> m_xCC), UNO_QUERY); //xBrd is still empty, not sure why?
>
>
Stephan, thank you for your kind and important correct. It works now. In
addition, from the link
(http://www.openoffice.org/api/docs/common/ref/com/sun/star/sdb/OfficeDatabaseDocument.html),
I saw that both "OnPrepareUnload" and "OnUnload" events are synchronously
broadcaster. Does it mean SolarMutex protection again? I really hope it does
not.
Thank you again,
Wendi
--
View this message in context:
http://nabble.documentfoundation.org/Solarmutex-Deadlock-when-Closing-Calc-which-contains-functions-with-XVolatileResult-return-values-tp3998056p4001199.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
On 08/14/2012 12:35 AM, anwen wrote:
I implemented the above code with c++ . However, it did not work. Anything
wrong with the following code:
m_xCC is a given Reference
Reference
xBrd(m_xCC->getServiceManager()->createInstanceWithContext(OUString(RTL_CONSTASCII_USTRINGPARAM("com.sun.star.frame.GlobalEventbroadcaster")),
it's "GlobalEventBroadcaster" (with a capital "B")
Stephan
m_xCC), UNO_QUERY); //xBrd is still empty, not sure why?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
Michael Stahl-2 wrote
>
> On 09/08/12 15:56, anwen wrote:
>> I am also interested in XDocumentEventBroadcaster/XDocumentEventListener.
>> I
>> am wondering if you could correct my following code which tries to
>> register
>> a XDocumentListener with the XDocumentEventBroadcaster in a Calc
>> Extension.
>> I did some research on this topic. Most of examples initialize a
>> EventBroadcaster following a bootstrap() method which could not be used
>> in
>> Calc Extension.
>
> i don't think documents implement XDocumentEventBroadcaster, but there
> is a GlobalEventBroadcaster service that you can get from the service
> factory:
>
> Object oGEB = m_xMSF.createInstance(
> "com.sun.star.frame.GlobalEventBroadcaster");
> m_xGEB = UnoRuntime.queryInterface(XDocumentEventBroadcaster.class,
> oGEB);
>
> iirc the DocumentEvent that your listener gets then contains something
> that identifies the document that the event is for.
>
>
I implemented the above code with c++ . However, it did not work. Anything
wrong with the following code:
m_xCC is a given Reference
Reference
xBrd(m_xCC->getServiceManager()->createInstanceWithContext(OUString(RTL_CONSTASCII_USTRINGPARAM("com.sun.star.frame.GlobalEventbroadcaster")),
m_xCC), UNO_QUERY); //xBrd is still empty, not sure why?
if (xBrd.is())
{
Reference< XEventListener > xDocListener(
static_cast(new CalcListener()),
UNO_QUERY);
xBrd->addEventListener(xDocListener);
}
Thanks,
Wendi
--
View this message in context:
http://nabble.documentfoundation.org/Solarmutex-Deadlock-when-Closing-Calc-which-contains-functions-with-XVolatileResult-return-values-tp3998056p4001090.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
On 08/10/2012 03:35 PM, anwen wrote: Stephan Bergmann-2 wrote I think you should execute your shutdown activies on notifyTermination, not queryTermination. The latter can be veto'ed by some other listener, in which case Desktop would cancel the termination and continue running (and notify you with queryTermination eventually followed by notifyTermination again later on). Thank you for your suggestion. Yes, queryTermination should be a place to set up some status changes. And real stop or shutdown a process should be done in notifyTermination. BTW, I saw that there is a XTerminationListener2 where cancelTermination() is called when the master environment (e.g., desktop) was canceled in it's terminate request. Is it good to use this interface? As long as you only listen on notifyTermination, you don't need to support the derived XTerminationListener2. That queryTermination is called with SolarMutex locked is a bug. (Is notifyTermination also called with SolarMutex locked? Would need to check, in framework/source/services/desktop.cxx.) However, it might be a bug not easy to fix without opening any number of pandora's boxes... Is there a bug report number regarding this issue? I would like to check its progress in the future. In addition, since notifyTermination is also protected by SolarMutex, I am wondering if you see any workaround to deal with such a deadlock issue related to multithread shutdown. Thank you. I'm not aware of any specific bug for this. I see no workaround short of a proper fix. And a proper fix would mean to (a) identify the place up the call stack from Desktop::terminate where SolarMutex is locked (I assume that TransactionGuard is not SolarMutex, but yet another locking for Desktop's private parts, but I may be wrong), (b) redesign that code path so that Desktop::terminate can call notifyTermination without SolarMutex, (c) see if any of the existing listeners on notifyTermination exploited the fact that they used to be called with SolarMutex locked and need to be adapted now. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
Stephan Bergmann-2 wrote > > > I think you should execute your shutdown activies on notifyTermination, > not queryTermination. The latter can be veto'ed by some other listener, > in which case Desktop would cancel the termination and continue running > (and notify you with queryTermination eventually followed by > notifyTermination again later on). > > Thank you for your suggestion. Yes, queryTermination should be a place to set up some status changes. And real stop or shutdown a process should be done in notifyTermination. BTW, I saw that there is a XTerminationListener2 where cancelTermination() is called when the master environment (e.g., desktop) was canceled in it's terminate request. Is it good to use this interface? Stephan Bergmann-2 wrote > > > That queryTermination is called with SolarMutex locked is a bug. (Is > notifyTermination also called with SolarMutex locked? Would need to > check, in framework/source/services/desktop.cxx.) However, it might be > a bug not easy to fix without opening any number of pandora's boxes... > > Is there a bug report number regarding this issue? I would like to check its progress in the future. In addition, since notifyTermination is also protected by SolarMutex, I am wondering if you see any workaround to deal with such a deadlock issue related to multithread shutdown. Thank you. Best, Wendi -- View this message in context: http://nabble.documentfoundation.org/Solarmutex-Deadlock-when-Closing-Calc-which-contains-functions-with-XVolatileResult-return-values-tp3998056p4000440.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
Thank you, Michael. This will solve my doubt with XDocumentEventBroadcaster. I will publish my experience and c++ code with XTermination, XGlobalEventBroadcaster/XEventListener, and also mutithread at Openoffice/Libreoffice Extension developers forums after I finish the project. Then others can benefit from my experience. Best, Wendi Michael Stahl-2 wrote > > On 09/08/12 15:56, anwen wrote: >> I am also interested in XDocumentEventBroadcaster/XDocumentEventListener. >> I >> am wondering if you could correct my following code which tries to >> register >> a XDocumentListener with the XDocumentEventBroadcaster in a Calc >> Extension. >> I did some research on this topic. Most of examples initialize a >> EventBroadcaster following a bootstrap() method which could not be used >> in >> Calc Extension. > > i don't think documents implement XDocumentEventBroadcaster, but there > is a GlobalEventBroadcaster service that you can get from the service > factory: > > Object oGEB = m_xMSF.createInstance( > "com.sun.star.frame.GlobalEventBroadcaster"); > m_xGEB = UnoRuntime.queryInterface(XDocumentEventBroadcaster.class, > oGEB); > > iirc the DocumentEvent that your listener gets then contains something > that identifies the document that the event is for. > > > ___ > LibreOffice mailing list > LibreOffice@.freedesktop > http://lists.freedesktop.org/mailman/listinfo/libreoffice > -- View this message in context: http://nabble.documentfoundation.org/Solarmutex-Deadlock-when-Closing-Calc-which-contains-functions-with-XVolatileResult-return-values-tp3998056p4000212.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
On 09/08/12 15:56, anwen wrote: > I am also interested in XDocumentEventBroadcaster/XDocumentEventListener. I > am wondering if you could correct my following code which tries to register > a XDocumentListener with the XDocumentEventBroadcaster in a Calc Extension. > I did some research on this topic. Most of examples initialize a > EventBroadcaster following a bootstrap() method which could not be used in > Calc Extension. i don't think documents implement XDocumentEventBroadcaster, but there is a GlobalEventBroadcaster service that you can get from the service factory: Object oGEB = m_xMSF.createInstance( "com.sun.star.frame.GlobalEventBroadcaster"); m_xGEB = UnoRuntime.queryInterface(XDocumentEventBroadcaster.class, oGEB); iirc the DocumentEvent that your listener gets then contains something that identifies the document that the event is for. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
anwen wrote
>
>
> BTW, I am not sure how to initialize a XDocumentEventBroadcaster which you
> mentioned previously in a Calc Extension. I tried this method:
> Reference
> xCalc(m_xCC->getServiceManager()->createInstanceWithContext(OUString(RTL_CONSTASCII_USTRINGPARAM("com.sun.star.sheet.SpreadsheetDocument")),
> m_xCC), UNO_QUERY); But it did not work.
>
>
I am also interested in XDocumentEventBroadcaster/XDocumentEventListener. I
am wondering if you could correct my following code which tries to register
a XDocumentListener with the XDocumentEventBroadcaster in a Calc Extension.
I did some research on this topic. Most of examples initialize a
EventBroadcaster following a bootstrap() method which could not be used in
Calc Extension.
void SAL_CALL BLPAPIAddIn_Impl::addDocEvtListener() throw (RuntimeException)
{
// Reference xModel = UnoRuntime.queryInterface(XModel.class,
uno::UNO_QUERY);
Reference
xCalc(m_xCC->getServiceManager()->createInstanceWithContext(OUString(RTL_CONSTASCII_USTRINGPARAM("com.sun.star.sheet.SpreadsheetDocument")),
m_xCC), UNO_QUERY);
if (xCalc.is())
{
Reference< XDocumentEventBroadcaster > xBroadcaster(xCalc,
UNO_QUERY);
if (xBroadcaster.is())
{
Reference< XDocumentEventListener > xDocListener(
static_cast(new CalcListener()), UNO_QUERY);
xBroadcaster->addDocumentEventListener(xDocListener);
std::cout << "added an DocEvtListener" << std::endl;
}
}
}
Thanks a lot.
--
View this message in context:
http://nabble.documentfoundation.org/Solarmutex-Deadlock-when-Closing-Calc-which-contains-functions-with-XVolatileResult-return-values-tp3998056p4000189.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
Thank you everyone for your kind and quick response. Stephan, I checked the impl_sendNotifyTerminationEvent in desktop.cxx. Yes, it is protected by TransactionGuard aTransaction( m_aTransactionManager, E_HARDEXCEPTIONS ), the same as impl_sendQueryTerminationEvent, :-( Stephan Bergmann-2 wrote > > On 08/08/2012 08:34 PM, anwen wrote: >> With the TerminateListener, I successfully get the desktop termination >> event >> by queryTermination() function. Although you told me that I could veto >> this >> termination signal by throwing TerminationVetoException. I am not sure >> how >> and where to handle the TerminationVetoException and re-call >> XDesktop.terminate() to finally close the office. So I tried to handle >> everything inside queryTermination(). > > I think you should execute your shutdown activies on notifyTermination, > not queryTermination. The latter can be veto'ed by some other listener, > in which case Desktop would cancel the termination and continue running > (and notify you with queryTermination eventually followed by > notifyTermination again later on). > >> However, deadlock happened sometimes again. Here is my analysis: this >> function is called by the main thread and is protected by the SolarMutex. >> If >> a modified() function is called by the worker thread at the same time, >> the >> worker thread is waiting for the SolarMutex. Then the main thread tries >> to >> stop the worker thread by calling realtime_session->stop(). This session >> is >> designed with thread safe strategy by a third-party. It fails to close >> the >> worker thread because the worker thread is waiting for the Main thread to >> release the SolarMutex. > > That queryTermination is called with SolarMutex locked is a bug. (Is > notifyTermination also called with SolarMutex locked? Would need to > check, in framework/source/services/desktop.cxx.) However, it might be > a bug not easy to fix without opening any number of pandora's boxes... > > Stephan > ___ > LibreOffice mailing list > LibreOffice@.freedesktop > http://lists.freedesktop.org/mailman/listinfo/libreoffice > -- View this message in context: http://nabble.documentfoundation.org/Solarmutex-Deadlock-when-Closing-Calc-which-contains-functions-with-XVolatileResult-return-values-tp3998056p4000178.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
On 08/09/2012 01:21 PM, Michael Stahl wrote: WTF, there is an API to release SolarMutex? ... /me hides under desk Yes, and its a gross, broken hack, never to be used. (As the outer code that locked the SolarMutex presumably did so to be able to temporarily break invariants. Now if inner code temporarily unlocks the SolarMutex, other code could observe broken invariants and fail, etc.) Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
On Thu, 2012-08-09 at 13:21 +0200, Michael Stahl wrote: > On 09/08/12 12:50, Michael Meeks wrote: > > > In case things arn't tangled enough - you can release the SolarMutex in > > your current thread and give another thread a chance to get in using > > XToolkit's "reschedule" method. Whether that is likely to make your life > > only yet more tangled is unclear to me ;-) > > WTF, there is an API to release SolarMutex? ... /me hides under desk Um right ;-) well - at least - I -assume- it instantiates the relevant Yield class which recursively drops the SolarMutex, then spins the mainloop and after processing an event (prolly a cursor blink would be a fall-back timeout ;-) it comes back, or perhaps doesn't come back because another thread got ownership of the mainloop / solar-mutex. Just another good example of why we badly need a minimal, small, simple, easy-to-understand, Objects-with-methods-not-meta-interfaces, cleanish API with an ABI break from the past ;-) [ and simultaneously IMHO to adapt UNO to target a superset of well-defined exposing-scripting functionality ]. ATB, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
On 09/08/12 12:50, Michael Meeks wrote: > In case things arn't tangled enough - you can release the SolarMutex in > your current thread and give another thread a chance to get in using > XToolkit's "reschedule" method. Whether that is likely to make your life > only yet more tangled is unclear to me ;-) WTF, there is an API to release SolarMutex? ... /me hides under desk ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
Hi there, On Wed, 2012-08-08 at 11:34 -0700, anwen wrote: > Although you told me that I could veto this termination signal by throwing > TerminationVetoException. I am not sure how and where to handle the > TerminationVetoException and re-call XDesktop.terminate() to finally > close the office. Presumably you could spawn another thread to wait until you've finished what you're doing and call XDesktop.terminate() later ? > Since the SolarMutex is everywhere, do you have any suggestion to clear it > for a while and give a chance to close the worker thread ? In case things arn't tangled enough - you can release the SolarMutex in your current thread and give another thread a chance to get in using XToolkit's "reschedule" method. Whether that is likely to make your life only yet more tangled is unclear to me ;-) Hope that helps, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
On 08/08/2012 08:34 PM, anwen wrote: With the TerminateListener, I successfully get the desktop termination event by queryTermination() function. Although you told me that I could veto this termination signal by throwing TerminationVetoException. I am not sure how and where to handle the TerminationVetoException and re-call XDesktop.terminate() to finally close the office. So I tried to handle everything inside queryTermination(). I think you should execute your shutdown activies on notifyTermination, not queryTermination. The latter can be veto'ed by some other listener, in which case Desktop would cancel the termination and continue running (and notify you with queryTermination eventually followed by notifyTermination again later on). However, deadlock happened sometimes again. Here is my analysis: this function is called by the main thread and is protected by the SolarMutex. If a modified() function is called by the worker thread at the same time, the worker thread is waiting for the SolarMutex. Then the main thread tries to stop the worker thread by calling realtime_session->stop(). This session is designed with thread safe strategy by a third-party. It fails to close the worker thread because the worker thread is waiting for the Main thread to release the SolarMutex. That queryTermination is called with SolarMutex locked is a bug. (Is notifyTermination also called with SolarMutex locked? Would need to check, in framework/source/services/desktop.cxx.) However, it might be a bug not easy to fix without opening any number of pandora's boxes... Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
Hi Eike,
Thank you for your advices. After doing some research, I decided to use
XTerminateListener which is registered with the LibreOffice desktop. The
reason is that once the Calc extension gets started, it is alive until the
desktop termination. So does the worker thread associated with the
Extension.
With the TerminateListener, I successfully get the desktop termination event
by queryTermination() function. Although you told me that I could veto this
termination signal by throwing TerminationVetoException. I am not sure how
and where to handle the TerminationVetoException and re-call
XDesktop.terminate() to finally close the office. So I tried to handle
everything inside queryTermination().
Here is my code:
void SAL_CALL CalcTerminateListener::queryTermination(const
::com::sun::star::lang::EventObject& aEvent)
throw( ::com::sun::star::frame::TerminationVetoException,
::com::sun::star::uno::RuntimeException )
{
if (realtime_session)
{
std::cout << "will close real time session" << std::endl;
realtime_session->stop();
std::cout << "closed real time session" << std::endl;
}
}
However, deadlock happened sometimes again. Here is my analysis: this
function is called by the main thread and is protected by the SolarMutex. If
a modified() function is called by the worker thread at the same time, the
worker thread is waiting for the SolarMutex. Then the main thread tries to
stop the worker thread by calling realtime_session->stop(). This session is
designed with thread safe strategy by a third-party. It fails to close the
worker thread because the worker thread is waiting for the Main thread to
release the SolarMutex.
Since the SolarMutex is everywhere, do you have any suggestion to clear it
for a while and give a chance to close the worker thread? or How and where
to handle the TerminationVetoException. It is not clear in the Developer's
guide. Thank you very much.
In case that someone is interested with registration of terminatelistener.
Here is my code:
::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext >
m_xCC; // it is assigned when initializing the extension.
xDesktop(m_xCC->getServiceManager()->createInstanceWithContext(OUString(RTL_CONSTASCII_USTRINGPARAM("com.sun.star.frame.Desktop")),
m_xCC), UNO_QUERY);
if (!xDesktop.is())
{
std::cout << "failed to find the desktop" << std::endl;
return;
}
Reference myListener = new
CalcTerminateListener(&blp_conn);
xDesktop->addTerminateListener(myListener);
std::cout << "added an TerminateListener" << std::endl;
BTW, I am not sure how to initialize a XDocumentEventBroadcaster which you
mentioned previously in a Calc Extension. I tried this method:
Reference
xCalc(m_xCC->getServiceManager()->createInstanceWithContext(OUString(RTL_CONSTASCII_USTRINGPARAM("com.sun.star.sheet.SpreadsheetDocument")),
m_xCC), UNO_QUERY); But it did not work.
Thank you for any suggestion.
Best,
Wendi
Eike Rathke-2 wrote
>
> Hi anwen,
>
> On Wednesday, 2012-08-01 07:57:00 -0700, anwen wrote:
>
>> Here is a minor remind that modified() is a method
>> of XResultListener (not XVolatileResult).
>
> Bah, yes, of course, thanks.
>
>> It is implemented in Calc by SCAddInListener class.
>
> I know, see my .signature below ;-)
>
> Eike
>
> --
> LibreOffice Calc developer. Number formatter stricken i18n
> transpositionizer.
> GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
>
> _______
> LibreOffice mailing list
> LibreOffice@.freedesktop
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
--
View this message in context:
http://nabble.documentfoundation.org/Solarmutex-Deadlock-when-Closing-Calc-which-contains-functions-with-XVolatileResult-return-values-tp3998056p384.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
Hi anwen, On Wednesday, 2012-08-01 07:57:00 -0700, anwen wrote: > Here is a minor remind that modified() is a method > of XResultListener (not XVolatileResult). Bah, yes, of course, thanks. > It is implemented in Calc by SCAddInListener class. I know, see my .signature below ;-) Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgppUTdBpPnfF.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
Hi Eike, Thank you for your quick and nice response. I am checking out the events and classes you recommended. Here is a minor remind that modified() is a method of XResultListener (not XVolatileResult). It is implemented in Calc by SCAddInListener class. Best, Wendi Eike Rathke-2 wrote > > Hi anwen, > > On Tuesday, 2012-07-31 08:30:30 -0700, anwen wrote: > >> Eike, I agree with you that the listeners are destroyed during document >> close. I observed it in my log file. However, the worker thread is >> running >> asynchronously if not calling the listeners' modified function. How can >> it >> know that the document is closed, stop calling the modified function, and >> quit itself gracefully. So in the first post, I asked if there is a >> signal >> which announces that the document is closed. > > There are two events that could be used, OnPrepareUnload that afair is > vetoable so your application could finish something it needs the > document for, and the unconditional OnUnload event. For both events you > could switch off calling the corresponding modified() when received. > > For general handling see > http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Document_Events > > However, that's a bit outdated and instead of the deprecated > XEventBroadcaster and XEventListener the successors > XDocumentEventBroadcaster and XDocumentEventListener interfaces should > be used, see > http://api.libreoffice.org/common/ref/com/sun/star/document/XDocumentEventBroadcaster.html > > > Still, for the apparent race condition I'd like to see if Calc's > XVolatileResult::modified() implementation could be changed such that in > case the corresponding document is in close the mutex isn't attempted to > be locked anymore. > > >> Please correct me if there is something wrong with my thought. > > No, nothing :-) > > Eike > > -- > LibreOffice Calc developer. Number formatter stricken i18n > transpositionizer. > GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD > > ___ > LibreOffice mailing list > LibreOffice@.freedesktop > http://lists.freedesktop.org/mailman/listinfo/libreoffice > -- View this message in context: http://nabble.documentfoundation.org/Solarmutex-Deadlock-when-Closing-Calc-which-contains-functions-with-XVolatileResult-return-values-tp3998056p3998808.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
Hi anwen, On Tuesday, 2012-07-31 08:30:30 -0700, anwen wrote: > Eike, I agree with you that the listeners are destroyed during document > close. I observed it in my log file. However, the worker thread is running > asynchronously if not calling the listeners' modified function. How can it > know that the document is closed, stop calling the modified function, and > quit itself gracefully. So in the first post, I asked if there is a signal > which announces that the document is closed. There are two events that could be used, OnPrepareUnload that afair is vetoable so your application could finish something it needs the document for, and the unconditional OnUnload event. For both events you could switch off calling the corresponding modified() when received. For general handling see http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Document_Events However, that's a bit outdated and instead of the deprecated XEventBroadcaster and XEventListener the successors XDocumentEventBroadcaster and XDocumentEventListener interfaces should be used, see http://api.libreoffice.org/common/ref/com/sun/star/document/XDocumentEventBroadcaster.html Still, for the apparent race condition I'd like to see if Calc's XVolatileResult::modified() implementation could be changed such that in case the corresponding document is in close the mutex isn't attempted to be locked anymore. > Please correct me if there is something wrong with my thought. No, nothing :-) Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpcRdgliwxFa.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
Eike, I agree with you that the listeners are destroyed during document close. I observed it in my log file. However, the worker thread is running asynchronously if not calling the listeners' modified function. How can it know that the document is closed, stop calling the modified function, and quit itself gracefully. So in the first post, I asked if there is a signal which announces that the document is closed. Please correct me if there is something wrong with my thought. Best, Wendi Eike Rathke-2 wrote > > Hi anwen, > > On Friday, 2012-07-27 08:43:25 -0700, anwen wrote: > >> The deadlock scenario is that the spreadsheet called the functions many >> times and was showing dynamical financial data. Then I closed the >> spreadsheet window. The window quit immediately, but the soffice.bin and >> soffice.exe were still in task manager. I had to kill these processes >> manually. From the log file, I saw that main thread hung at destruction >> process, trying to close the second thread, and the second thread hang at >> Reference -> modified(), trying to update the >> spreadsheet. > > This sounds like the actual culprit. The result listener should not try > to update if the document is in destruction. Actually the listeners are > detroyed during document close, but it seems this is a race condition > and a modified() is fired in between. If it detected that situation it > wouldn't need to lock SolarMutex but could bail out early instead. > > Could you please submit a bug for this and assign it to me? > > Thanks > Eike > > -- > LibreOffice Calc developer. Number formatter stricken i18n > transpositionizer. > GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD > > ___ > LibreOffice mailing list > LibreOffice@.freedesktop > http://lists.freedesktop.org/mailman/listinfo/libreoffice > -- View this message in context: http://nabble.documentfoundation.org/Solarmutex-Deadlock-when-Closing-Calc-which-contains-functions-with-XVolatileResult-return-values-tp3998056p3998638.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
Eike, thank you for your kind response. I just now submitted a bug report with the same title. I attached a text file which is the analyzed result of a full dump file. If you are assigned this bug and would like to check out the full/mini dump files, or need more information, please feel free to let me know. BTW, in my previous post, you can see part of the analyzed result. Thanks, Wendi Eike Rathke-2 wrote > > Hi anwen, > > On Friday, 2012-07-27 08:43:25 -0700, anwen wrote: > >> The deadlock scenario is that the spreadsheet called the functions many >> times and was showing dynamical financial data. Then I closed the >> spreadsheet window. The window quit immediately, but the soffice.bin and >> soffice.exe were still in task manager. I had to kill these processes >> manually. From the log file, I saw that main thread hung at destruction >> process, trying to close the second thread, and the second thread hang at >> Reference -> modified(), trying to update the >> spreadsheet. > > This sounds like the actual culprit. The result listener should not try > to update if the document is in destruction. Actually the listeners are > detroyed during document close, but it seems this is a race condition > and a modified() is fired in between. If it detected that situation it > wouldn't need to lock SolarMutex but could bail out early instead. > > Could you please submit a bug for this and assign it to me? > > Thanks > Eike > > -- > LibreOffice Calc developer. Number formatter stricken i18n > transpositionizer. > GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD > > ___ > LibreOffice mailing list > LibreOffice@.freedesktop > http://lists.freedesktop.org/mailman/listinfo/libreoffice > -- View this message in context: http://nabble.documentfoundation.org/Solarmutex-Deadlock-when-Closing-Calc-which-contains-functions-with-XVolatileResult-return-values-tp3998056p3998635.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
BLPAPIAddIn_uno!com::telemetry::sheet::BLP_VolatileResult::newValue+0xdb
[y:\src\extension\src\blp_volatileresult.cpp @ 81]
11d2fcc8 07f7e9ea 11df0980 11df0980
BLPAPIAddIn_uno!com::telemetry::sheet::BLP_VolatileResult::processResponse+0x1d6
[y:\src\extension\src\blp_volatileresult.cpp @ 141]
11d2fd88 07f7ebe5 11d2fde0 ff8f4622 0dd4cd78
BLPAPIAddIn_uno!SubscriptionEventHandler::processSubscriptionDataEvent+0x18a
[y:\src\extension\src\blp\blp_mktdata.cpp @ 85]
11d2fdbc 07f66b93 11d2fde0 0d5223f8 ff8f464e
BLPAPIAddIn_uno!SubscriptionEventHandler::processEvent+0x75
[y:\src\extension\src\blp\blp_mktdata.cpp @ 155]
11d2fdd8 081bb7b5 11dbdb30 083d8308 0d5223f8
BLPAPIAddIn_uno!BloombergLP::blpapi::eventHandlerProxy+0x43
[c:\users\wchen\documents\telemetry_bloomberg_api\blp\include\blpapi_session.h
@ 873]
WARNING: Stack unwind information not available. Following frames may be
wrong.
11d2fe48 08281aed 0829c530 7c90d8ba
blpapi3_32!blpapi_Session_getAbstractSession+0x95
11d2fe50 7c90d8ba 0dd4ccc8
blpapi3_32!blpapi_Name_destroy+0x6315d
11d2fe78 0829cc9f 0829dde0 11d2ff08
ntdll!NtQueryPerformanceCounter+0xc
11d2ff48 0829ded9 08297fa2 0dd4ccc8
blpapi3_32!blpapi_Name_destroy+0x7e30f
11d2ff4c 08297fa2 0dd4ccc8
blpapi3_32!blpapi_Name_destroy+0x7f549
11d2ff70 082c24fd 0dd42ca0 ff97fc8c
blpapi3_32!blpapi_Name_destroy+0x79612
blpapi3_32!blpapi_Name_destroy+0xa3b6d
!locks result
0:000> !locks
CritSec +40f6638 at 040f6638
LockCount 2
RecursionCount 2
OwningThread 1504
EntryCount 19
ContentionCount19
*** Locked
---!threads
0:000> !threads
Index TID TEB StackBase
StackLimit DeAlloc
StackSize ThreadProc
0 15040x7ffdf000 0x00e4 0x00e0e000
0x004b 0x00032000 0x40213c:
soffice!WinMainCRTStartup
1 15ec0x7ffde000 0x0582 0x0581f000
0x04e9 0x1000
0x10004930: sal3!rtl_cache_wsupdate_all
2 06d80x7ffdd000 0x061b 0x061ad000
0x0582 0x3000
0x4ec67456: GdiPlus!BackgroundThreadProc
3 08840x7ffdb000 0x08db 0x08daf000
0x0842 0x1000
0x7854345e: msvcr90!_endthreadex
4 02800x7ffda000 0x0abc 0x0abbf000
0x0a23 0x1000
0x77e76c7d: rpcrt4!ThreadStartRoutine
5 17500x7ffd9000 0x0b55 0x0b54f000
0x0abc 0x1000
0x774fe4ef: ole32!CRpcThreadCache::RpcWorkerThreadEntry
6 09180x7ffd4000 0x10a1 0x10a0f000
0x1008 0x1000
0x71a5d2c6: mswsock!SockAsyncThread
7 07180x7ffaf000 0x113a 0x1139f000
0x10a1 0x1000 0x82c2523:
blpapi3_32!blpapi_Name_destroy
8 17880x7ffae000 0x11d3 0x11d2b000
0x113a 0x5000 0x82c2523:
blpapi3_32!blpapi_Name_destroy
9 10ec0x7ffdc000 0x128c 0x128be000
0x11f3 0x2000
0x7854345e: msvcr90!_endthreadex
10 152c0x7ffad000 0x1325 0x1324f000
0x128c 0x1000
0x7854345e: msvcr90!_endthreadex
Total VM consumed by thread stacks 0x00043000
Stephan Bergmann-2 wrote
>
> On 07/27/2012 05:43 PM, anwen wrote:
>> After doing some research, I suspect that the deadlock is because of
>> SolarMutex. The main thread starts termination process, acquires
>> SolarMutex,
>> and tries to close the second thread. But the second thread can not
>> complete
>> if the Listener->modified() function is waiting for SolarMutex too.
>
> Sounds reasonable. The SolarMutex is a constant source of joy, and
> joining on a thread with SolarMutex locked sounds like a bad idea. To
> help understand your concrete problem better, can you please show the
> backtraces of the two deadlocked threads?
>
> Stephan
> ___
> LibreOffice mailing list
> LibreOffice@.freedesktop
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
--
View this message in context:
http://nabble.documentfoundation.org/Solarmutex-Deadlock-when-Closing-Calc-which-contains-functions-with-XVolatileResult-return-values-tp3998056p3998630.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
-- View this message in context: http://nabble.documentfoundation.org/Solarmutex-Deadlock-when-Closing-Calc-which-contains-functions-with-XVolatileResult-return-values-tp3998056p3998621.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
Hi anwen, On Friday, 2012-07-27 08:43:25 -0700, anwen wrote: > The deadlock scenario is that the spreadsheet called the functions many > times and was showing dynamical financial data. Then I closed the > spreadsheet window. The window quit immediately, but the soffice.bin and > soffice.exe were still in task manager. I had to kill these processes > manually. From the log file, I saw that main thread hung at destruction > process, trying to close the second thread, and the second thread hang at > Reference -> modified(), trying to update the spreadsheet. This sounds like the actual culprit. The result listener should not try to update if the document is in destruction. Actually the listeners are detroyed during document close, but it seems this is a race condition and a modified() is fired in between. If it detected that situation it wouldn't need to lock SolarMutex but could bail out early instead. Could you please submit a bug for this and assign it to me? Thanks Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpDyUMlxOQVk.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
On 07/27/2012 05:43 PM, anwen wrote: After doing some research, I suspect that the deadlock is because of SolarMutex. The main thread starts termination process, acquires SolarMutex, and tries to close the second thread. But the second thread can not complete if the Listener->modified() function is waiting for SolarMutex too. Sounds reasonable. The SolarMutex is a constant source of joy, and joining on a thread with SolarMutex locked sounds like a bad idea. To help understand your concrete problem better, can you please show the backtraces of the two deadlocked threads? Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values
Recently, I am working on developing a Calc extension for showing dynamic streaming data, such as Bloomberg and Reuters real time data. The extension is written in C++ for Windows OS and contains add-in functions for retrieving dynamic financial data. Based on the OpenOffice/LibreOffice developer's guide, the function returns XVolatileResult derived data type. There are two threads. The main thread deals with spreadsheet, such as calling functions. The second thread gets the streaming messages, processes them and notify spreadsheet (the main thread) data changes via Reference -> modified(EventResult) function within XVolatileResult derived object. The deadlock scenario is that the spreadsheet called the functions many times and was showing dynamical financial data. Then I closed the spreadsheet window. The window quit immediately, but the soffice.bin and soffice.exe were still in task manager. I had to kill these processes manually. From the log file, I saw that main thread hung at destruction process, trying to close the second thread, and the second thread hang at Reference -> modified(), trying to update the spreadsheet. After doing some research, I suspect that the deadlock is because of SolarMutex. The main thread starts termination process, acquires SolarMutex, and tries to close the second thread. But the second thread can not complete if the Listener->modified() function is waiting for SolarMutex too. This is a multi-threads issue. I saw a similar bug report at http://nabble.documentfoundation.org/Base-hangs-when-trying-to-close-it-td3798832.html A patch tried to solve the above bug: https://bugs.freedesktop.org/attachment.cgi?id=58176. However, this patch is reverted from release version LibreOffice 3.6.0 : http://wiki.documentfoundation.org/Releases/3.6.0/RC2 (do#47021 revert "attempt fix of hang on base close, due to solarmutex deadlock on join" [Michael Stahl]) . I am wondering if there is a signal which I can detect when the termination process starts. If yes, then I can prepare for the termination in the extension. Or if I can release the Solarmutex in my code to let thread 2 complete the modified() function? Any other suggestions? Thank you for your kind help. -- View this message in context: http://nabble.documentfoundation.org/Solarmutex-Deadlock-when-Closing-Calc-which-contains-functions-with-XVolatileResult-return-values-tp3998056.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
