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
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 "synch
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
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
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
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
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
Issues involving dirty cell, recalculation, and xvolatileresult in Libreoffice Calc
Hi All,
Recently, I am working on a Calc extension which is for dynamically showing
streaming financial data. I observed a conflict involving dirty cell,
recalculation, and xvolatilresult in Calc. From my view, it will be a
potential error or at least affect the performance of Calc if many changes
are made with the spreadsheet.
I am not very aware of the mechanism of dirty cell / auto recalculation with
XVolatileResult. From my observation, I guess that a XVolatileResult object
which is associated with a set of arguments can access to a list of
registered cells and update all of them if changes happen. If I change a
cell value which is part of the arguments, the formulas in the affected
(dirty) cells are recalculated automatically. This schema works well with
non-volatile result. However, with XVolatileResult, it raises some issues.
Briefly, the affected cells are still kept in the original list, and at the
same time register a new list associated with a new XVolatileResult object.
Both the original and new XVolatileResult objects update the dirty cells
when changes happen. These unnecessary and wrong callbacks definitely lower
Calc's performance.
I would like to describe the issues with a XVolatileResult example which is
listed in the Libreoffice SDK
(sdk->examples->DeveloperGuide->Spreadsheet->ExampleAddIn.java). You can
also check out the code from this link:
http://c-cpp.r3dcode.com/files/LibreOffice/3/4.5.2/sdk/odk/examples/DevelopersGuide/Spreadsheet/ExampleAddIn.java
Firstly, I added some trivial System.out.println() in this java file.
public void addResultListener(com.sun.star.sheet.XResultListener
aListener)
{
aListeners.addElement( aListener );
/*System.out.println("Adding a Listener. Total is " +
aListeners.size());*/
// immediately notify of initial value
aListener.modified( getResult() );
}
public void removeResultListener(com.sun.star.sheet.XResultListener
aListener)
{
aListeners.removeElement( aListener );
/*System.out.println("removing a listener. Total is " +
aListeners.size());*/
}
public void incrementValue()
{
++nValue;
com.sun.star.sheet.ResultEvent aEvent = getResult();
/*System.out.println("In incrementValue " + aEvent.Value);*/
java.util.Enumeration aEnum = aListeners.elements();
while (aEnum.hasMoreElements())
((com.sun.star.sheet.XResultListener)aEnum.nextElement()).modified(
aEvent);
/*System.out.println("Done incrementValue " + aEvent.Value);*/
}
class ExampleAddInThread extends Thread
{
private java.util.Hashtable aCounters;
public ExampleAddInThread( java.util.Hashtable aResults )
{
aCounters = aResults;
}
public void run()
{
while ( true )
{
try
{
sleep(500);
}
catch( InterruptedException exception )
{
}
/*System.out.println("will call incrementValue");*/
// increment all counters
java.util.Enumeration aEnum = aCounters.elements();
while (aEnum.hasMoreElements())
((ExampleAddInResult)aEnum.nextElement()).incrementValue();
}
}
}
public com.sun.star.sheet.XVolatileResult getCounter(String aName)
{
/ *System.out.println("calling getCounter with " + aName);*/
if ( aResults == null )
{
// create the table of results, and start a thread to
increment
// all counters
aResults = new java.util.Hashtable();
ExampleAddInThread aThread = new ExampleAddInThread(
aResults );
aThread.start();
}
ExampleAddInResult aResult = (ExampleAddInResult)
aResults.get(aName);
if ( aResult == null )
{
aResult = new ExampleAddInResult(aName);
aResults.put( aName, aResult );
}
return aResult;
}
Secondly, I compiled this extension and installed it with LibreOffice. Then,
since I was working in Windows XP, I ran from command line console the
command: soffice.exe 2>&1 > log.txt . Afterwards, a LibreOffice window was
opened and the standard system out was written in log.txt.
Thirdly, I launched a spreadsheet and did the following cases:
(1) inserted "1" in A1 and "=counter(A1)" in A2. Here counter is an addin
function provided by ExampleAddIn.java. The corresponding log is
/calling getCounter with 1
Adding a Listener. Total is 1
will call incrementValue
In incrementValue 1
calling getCounter with 1
Done incrementValue 1
/
Everything is good. To avoid confusion, I deleted all the dynamic count
numbers in the log file.
(2) changed "1" to "2" in A1. The corresponding log is
/calling getCounter with 2
Adding a Listener. Total is 1
will call incrementValue
In incrementValue 2
calling getCo
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
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: Base hangs when trying to close it
I am wondering if it is possible to release SolarMutex when I develop an extension for LibreOffice. I have a similar problem when I developing a Calc extension. Is there another method since this patch is reverted from release 3.6.0? Thank you. Michael Meeks-2 wrote > > On Mon, 2012-03-05 at 12:56 -0800, julien2412 wrote: >> I'm just a C++ beginner (and think i'll still be for years), it's far >> beyond >> my few skills sorry > > Hah ! you're doing really well for a beginner :-) > >> Now if someone propose a patch I can try to test again the closing of >> base. > > The attached might work, input / testing appreciated :-) particularly > of the other component's exit, and the results of 'make check' before > and after. > > Thanks, > > Michael. > > -- > michael.meeks@ <><, Pseudo Engineer, itinerant idiot > > ___ > LibreOffice mailing list > LibreOffice@.freedesktop > http://lists.freedesktop.org/mailman/listinfo/libreoffice > -- View this message in context: http://nabble.documentfoundation.org/Base-hangs-when-trying-to-close-it-tp3798832p3998057.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
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
Re: Regular Windows debug builds
Thank Jesús Corrius for your great effort of building and publishing the debug build. I do appreciate it. I downloaded the 3-5-3 version and would like to use it for debugging a crash caused by a spreadsheet extension. However, it requires symbol files (.pdb) to assist winDBG. I tried to build the LibreOffice by myself, but failed several times. I am wondering if you could share your symbol files associated with LibO-Dev_3.5.3rc1_Win_x86_install_en-US.msi or any of the win32 debug versions. Thank you again for your kind help. Best, Wendi -- View this message in context: http://nabble.documentfoundation.org/Regular-Windows-debug-builds-tp3822568p3995090.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
