Bug 53008 - SolarMutex deadlock when closing Calc which contains functions with XVolatileResult return values
Summary: SolarMutex deadlock when closing Calc which contains functions with XVolatile...
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.5.0 Beta2
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-31 15:09 UTC by Wendi Chen
Modified: 2017-06-28 12:33 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
The analyzed result of a full dump file (28.18 KB, text/plain)
2012-07-31 15:09 UTC, Wendi Chen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wendi Chen 2012-07-31 15:09:11 UTC
Created attachment 64997 [details]
The analyzed result of a full dump file

Problem description: 

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<XResultListener> -> 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<XResultLisenter> -> 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?

I attached the analyzed result of a full dump file which is created manually by Explorer Process (no crash with the processes hanging). If you'd like to check out the mini/full dump files, or need more information, please feel free to let me know. thanks.

Wendi

Steps to reproduce:
1. ....
2. ....
3. ....

Current behavior:

Expected behavior:

Platform (if different from the browser): Windows XP
       
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0
Comment 2 Joel Madero 2013-06-28 01:16:56 UTC
> 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?
> 

This comment makes me think it's not a bug report but instead a request for help but to confirm this - requesting input from developers
Comment 3 Eike Rathke 2013-06-28 14:34:08 UTC
It is actually a bug report because the implementation for XVolatileResult listeners/broadcasters has some quirks. AFAIR I asked Wendi to report that as a bug so it doesn't get lost. Alas, I didn't have time to dive into.
Comment 4 Robinson Tryon (qubit) 2013-10-19 00:58:53 UTC Comment hidden (obsolete)
Comment 5 Robinson Tryon (qubit) 2013-11-18 16:52:52 UTC
Bug is confirmed and NEW
Whiteboard: Removing 'Need_Advice'
Comment 6 QA Administrators 2015-04-19 03:20:53 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2016-09-20 09:24:22 UTC Comment hidden (obsolete)
Comment 8 Julien Nabet 2016-11-27 11:04:05 UTC
Any better with last stable LO version 5.2.3?
Comment 9 QA Administrators 2017-05-31 10:50:41 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2017-06-28 12:33:56 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-20170628