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
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
Thank you, Stephan and Michael. Stephan, I will explain my observations with the Doc events later. Michael, would you mind explaining more about figuring out how to fix all that without losing the synchronous nature of the notification that i bet extensions depend upon? As an extension Developer, instead of a LibreOffice developer, I have no clue of it right now, :-( 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. 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. Michael Meeks suggested me to veto and then call XDesktop.terminate() within the code. I tried it but finally gave up because 1, the Calc extension is not a complete process and has not a main() function. 2, the worker thread is not suggested to stop and kill itself. So I am not sure where to call the XDesktop.terminate() after veto. I hope that my observations and the discussion here could help LibreOffice improve its support to multi-threads extensions, especially XVolatileResult related. Thanks, Wendi Michael Stahl-2 wrote 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
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 ReferenceXComponentContext ReferenceXEventBroadcaster 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
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 ReferenceXComponentContext ReferenceXEventBroadcaster 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 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
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 ReferenceXComponentContext
ReferenceXEventBroadcaster
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_castXEventListener*(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
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 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 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
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 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
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
anwen wrote
BTW, I am not sure how to initialize a XDocumentEventBroadcaster which you
mentioned previously in a Calc Extension. I tried this method:
ReferenceXSpreadsheetDocument
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)
{
// ReferenceXModel xModel = UnoRuntime.queryInterface(XModel.class,
uno::UNO_QUERY);
ReferenceXSpreadsheetDocument
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_castXDocumentEventListener*(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
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
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
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;
}
ReferenceXTerminateListener 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:
ReferenceXSpreadsheetDocument
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 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
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 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 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 ReferenceXResultLisenter - 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
-- 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
Stephan, thank you for your kind and response. There is not a crash when I closed the spreadsheet window and the processes still hung. I used explorer process to create a mini dump file and a full dump file. Then I analyzed the dump files at WinDBG. There are more than two threads, and I posted the back trace of two problem related threads at the end of my response. blpapi3_32.dll is a 3rd party API for providing streaming data. BLPAPIAddIn_uno is my code for a spreadsheet extension. Thanks, Wendi --Main thread . 0 Id: 1244.1504 Suspend: 0 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr Args to Child 00e3edfc 7c90df5a 7c8025db 03e4 ntdll!KiFastSystemCallRet 00e3ee00 7c8025db 03e4 ntdll!ZwWaitForSingleObject+0xc 00e3ee64 7c802542 03e4 kernel32!WaitForSingleObjectEx+0xa8 00e3ee78 08297b2e 03e4 083d5c58 kernel32!WaitForSingleObject+0x12 WARNING: Stack unwind information not available. Following frames may be wrong. 00e3ee94 0829978f 083d5c58 0dd4cc18 0dd4cba8 blpapi3_32!blpapi_Name_destroy+0x7919e 00e3eea8 081bda85 0dd4cc18 eea6ed9c 7c91137a blpapi3_32!blpapi_Name_destroy+0x7adff 00e3eed8 7c911460 7c9113e1 7c9113f2 7c91137a blpapi3_32!blpapi_SubscriptionItr_create+0x1115 00e3ef14 081c0690 083d8318 081c4533 0dd4cba8 ntdll!RtlpFreeDebugInfo+0x6a 00e3ef1c 081c4533 0dd4cba8 08378b5c eea6ec14 blpapi3_32!blpapi_SubscriptionItr_create+0x3d20 00e3ef44 7854f33b 0011 00e3ef8c 78550051 blpapi3_32!blpapi_SubscriptionItr_create+0x7bc3 00e3ef50 78550051 785b73c8 78550048 3993af06 msvcr90!_unlock_file+0x2d 00e3ef58 78550048 3993af06 07ce3d38 0803dc08 msvcr90!fflush+0x51 00e3ef8c 082ea803 0008 0829831e 0d5223f8 msvcr90!fflush+0x48 00e3efc0 07f69c88 0803dc08 07f7fa1c 0001 blpapi3_32!blpapi_Name_destroy+0xcbe73 00e3efc8 07f7fa1c 0001 eebe5446 07fb9490 BLPAPIAddIn_uno!BloombergLP::blpapi::Session::`scalar deleting destructor'+0x8 00e3eff8 07f72404 eebe4b9a 00e3f8e0 07ce3ce0 BLPAPIAddIn_uno!blp_mktdata::~blp_mktdata+0x6c [y:\src\extension\src\blp\blp_mktdata.cpp @ 289] 00e3f024 07f76708 02c2b450 00352dc2 0001 BLPAPIAddIn_uno!com::telemetry::sheet::BLPAPIAddIn_Impl::~BLPAPIAddIn_Impl+0x124 [y:\src\extension\src\blp_addin.cpp @ 154] 00e3f02c 00352dc2 0001 0102742f 07ce3ce0 BLPAPIAddIn_uno!com::telemetry::sheet::BLPAPIAddIn_Impl::`scalar deleting destructor'+0x8 00e3f044 0b571ba1 07ce3ce0 00e3f05c 01026306 cppuhelper3MSC!cppu::OWeakObject::release+0x42 [c:\git\libo\cppuhelper\source\weak.cxx @ 213] 00e3f050 01026306 07ce3cf8 00e3f08c 01026288 sclo!com::sun::star::uno::cpp_release+0x11 [c:\git\libo\solver\wntmsci12.pro\inc\com\sun\star\uno\genfunc.hxx @ 54] 00e3f05c 01026288 07ce3cf8 0b571b90 000e cppu3!cppu::_release+0x16 [c:\git\libo\cppu\source\uno\prim.hxx @ 103] 00e3f08c 01026580 079cc7c0 0b571b90 00e3f0b0 cppu3!cppu::_destructAny+0x2e8 [c:\git\libo\cppu\source\uno\destr.hxx @ 183] 00e3f09c 0b571d15 079cc7c0 0b571b90 079cc7c0 cppu3!uno_any_destruct+0x10 [c:\git\libo\cppu\source\uno\any.cxx @ 140] 00e3f0b0 0b738667 5e2bd32f 079cc7f0 079cc7a8 sclo!com::sun::star::uno::Any::~Any+0x15 [c:\git\libo\solver\wntmsci12.pro\inc\com\sun\star\uno\any.hxx @ 99] 00e3f0d8 0b73913f 079cc7a8 00e3f12c 0b7390b2 sclo!ScUnoAddInFuncData::~ScUnoAddInFuncData+0x87 [c:\git\libo\sc\source\core\tool\addincol.cxx @ 116] 00e3f0e4 0b7390b2 0001 079cc6b8 0794e318 sclo!ScUnoAddInFuncData::`scalar deleting destructor'+0xf 00e3f12c 0b738faf 079b3f90 00e3f144 0b6e23ef sclo!ScUnoAddInCollection::Clear+0xf2 [c:\git\libo\sc\source\core\tool\addincol.cxx @ 278] 00e3f138 0b6e23ef 079b3f90 00e3f284 0b6e1d15 sclo!ScUnoAddInCollection::~ScUnoAddInCollection+0xf [c:\git\libo\sc\source\core\tool\addincol.cxx @ 268] 00e3f144 0b6e1d15 0001 00e3f224 7c91084c sclo!ScUnoAddInCollection::`scalar deleting destructor'+0xf 00e3f284 0b9a6d77 5e2bd13f 0790af58 0790af08 sclo!ScGlobal::Clear+0x105 [c:\git\libo\sc\source\core\data\global.cxx @ 653] 00e3f2c8 0b9a6b8f 0790e838 00e3f304 017ae1fd sclo!ScModule::~ScModule+0x147 [c:\git\libo\sc\source\ui\app\scmod.cxx @ 208] 00e3f2d4 017ae1fd 0001 078981f4 00e3f340 sclo!ScModule::`scalar deleting destructor'+0xf 00e3f304 01756c51 3b7bfc0c 00e3f35c sfxlo!SfxModule::DestroyModules_Impl+0x6d [c:\git\libo\sfx2\source\appl\module.cxx @ 338] 00e3f354 017511ad 078981f0 00e3f3d8 01768a76 sfxlo!SfxApplication::~SfxApplication+0xb1 [c:\git\libo\sfx2\source\appl\app.cxx @ 352] 00e3f360 01768a76 0001 3b7bfc80 00e3f37c sfxlo!SfxApplication::`vector deleting destructor'+0x4d 00e3f3d8 0931dc70 07263e08 00e3f46c b7214404 sfxlo!SfxTerminateListener_Impl::notifyTermination+0x296 [c:\git\libo\sfx2\source\appl\appinit.cxx @ 140] 00e3f490 09280fdb 07251044 b721447c 07251044 fwklo!framework::Desktop::terminate+0x520 [c:\git\libo\framework\source\services\desktop.cxx @ 424] 00e3f4e8 09280332 b72146a4 00e3f8e0 02c2b450 fwklo!framework::CloseDispatcher::implts_terminateApplication+0x10b
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 ReferenceXResultLisenter - 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
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 ReferenceXResultLisenter - 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
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
