Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values

classic Classic list List threaded Threaded
29 messages Options
Next » 12
anwen anwen
Reply | Threaded
Open this post in threaded view
|

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

Thank you for your kind help.
sberg sberg
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Eike Rathke-2 Eike Rathke-2
Reply | Threaded
Open this post in threaded view
|

Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values

In reply to this post by anwen
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<XResultLisenter> -> 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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

attachment0 (205 bytes) Download Attachment
anwen anwen
Reply | Threaded
Open this post in threaded view
|

Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values

In reply to this post by sberg
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 000003e4 00000000 ntdll!KiFastSystemCallRet
00e3ee00 7c8025db 000003e4 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc
00e3ee64 7c802542 000003e4 ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xa8
00e3ee78 08297b2e 000003e4 ffffffff 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 00000011 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 00000008 0829831e 0d5223f8 msvcr90!fflush+0x48
00e3efc0 07f69c88 0803dc08 07f7fa1c 00000001 blpapi3_32!blpapi_Name_destroy+0xcbe73
00e3efc8 07f7fa1c 00000001 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 00000001 BLPAPIAddIn_uno!com::telemetry::sheet::BLPAPIAddIn_Impl::~BLPAPIAddIn_Impl+0x124 [y:\src\extension\src\blp_addin.cpp @ 154]
00e3f02c 00352dc2 00000001 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 0000000e 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 00000001 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 00000001 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 00000001 078981f4 00e3f340 sclo!ScModule::`scalar deleting destructor'+0xf
00e3f304 01756c51 3b7bfc0c ffffffff 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 00000001 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 [c:\git\libo\framework\source\dispatch\closedispatcher.cxx @ 585]
00e3f630 0927febf 00000000 00e3f654 01174764 fwklo!framework::CloseDispatcher::impl_asyncCallback+0x462 [c:\git\libo\framework\source\dispatch\closedispatcher.cxx @ 417]
00e3f63c 01174764 0e0c286c 00000000 00000000 fwklo!framework::CloseDispatcher::LinkStubimpl_asyncCallback+0xf [c:\git\libo\framework\source\dispatch\closedispatcher.cxx @ 269]
00e3f654 02afca00 00000000 0e0c28b0 00e3f670 tllo!Link::Call+0x24 [c:\git\libo\tools\inc\tools\link.hxx @ 140]
00e3f664 02afca1f 00000000 00e3f688 01174764 vcllo!vcl::EventPoster::DoEvent_Impl+0x20 [c:\git\libo\vcl\source\helper\evntpost.cxx @ 60]
00e3f670 01174764 0e0c28b0 00000000 00e3f68c vcllo!vcl::EventPoster::LinkStubDoEvent_Impl+0xf [c:\git\libo\vcl\source\helper\evntpost.cxx @ 62]
00e3f688 02bd73ac 00000000 00e3f69c 00000030 tllo!Link::Call+0x24 [c:\git\libo\tools\inc\tools\link.hxx @ 140]
00e3f6a8 02bd558d 0d917cd0 02c2b450 0d917cd0 vcllo!ImplHandleUserEvent+0xac [c:\git\libo\vcl\source\window\winproc.cxx @ 2000]
00e3f774 02c21e0e 07899a30 07899cd0 00000016 vcllo!ImplWindowFrameProc+0x55d [c:\git\libo\vcl\source\window\winproc.cxx @ 2571]
00e3f794 02c287fc 00000016 0d917cd0 07899cd0 vcllo!SalFrame::CallCallback+0x2e [c:\git\libo\vcl\inc\salframe.hxx @ 294]
00e3f7a8 02c2689a 000503fc 0d917cd0 3301b8fa vcllo!ImplHandleUserEvent+0x2c [c:\git\libo\vcl\win\source\window\salframe.cxx @ 4376]
00e3f828 02c2b4b1 000503fc 00000482 00000000 vcllo!SalFrameWndProc+0x70a [c:\git\libo\vcl\win\source\window\salframe.cxx @ 6002]
00e3f878 7e418734 000503fc 00000482 00000000 vcllo!SalFrameWndProcW+0x61 [c:\git\libo\vcl\win\source\window\salframe.cxx @ 6150]
00e3f8a4 7e418816 02c2b450 000503fc 00000482 user32!InternalCallWinProc+0x28
00e3f90c 7e4189cd 00000000 02c2b450 000503fc user32!UserCallWinProcCheckWow+0x150
00e3f96c 7e418a10 00e3f9ac 00000000 00e3f988 user32!DispatchMessageWorker+0x306
00e3f97c 02be166d 00e3f9ac 00e3f99c 02be9f95 user32!DispatchMessageW+0xf
00e3f988 02be9f95 00e3f9ac 00000000 040f7d00 vcllo!ImplDispatchMessage+0xd [c:\git\libo\vcl\win\source\app\saldata.cxx @ 150]
00e3f99c 02be9edd 00e3f9ac 00006638 000503fc vcllo!ImplSalDispatchMessage+0x35 [c:\git\libo\vcl\win\source\app\salinst.cxx @ 660]
00e3f9cc 02bea098 00000001 00000000 040f65f0 vcllo!ImplSalYield+0x5d [c:\git\libo\vcl\win\source\app\salinst.cxx @ 680]
00e3f9f4 0285560e 00000001 00000000 01e3fa1c vcllo!WinSalInstance::Yield+0xd8 [c:\git\libo\vcl\win\source\app\salinst.cxx @ 742]
00e3fa0c 0285569f 00000001 00000000 00e3fa2c vcllo!ImplYield+0x8e [c:\git\libo\vcl\source\app\svapp.cxx @ 459]
00e3fa1c 0285554b 00000000 02dc0f88 00e3fe60 vcllo!Application::Yield+0xf [c:\git\libo\vcl\source\app\svapp.cxx @ 492]
00e3fa2c 00278729 3b7cdd66 00404380 0005231e vcllo!Application::Execute+0x2b [c:\git\libo\vcl\source\app\svapp.cxx @ 435]
00e3fe60 02860a69 00e37677 046a54e0 040f63a8 sofficeapp!desktop::Desktop::Main+0x1ce9 [c:\git\libo\desktop\source\app\app.cxx @ 1887]
00e3fe98 02860b93 046a54e0 00e3ff04 002a5a9b vcllo!ImplSVMain+0x79 [c:\git\libo\vcl\source\app\svmain.cxx @ 178]
00e3fea4 002a5a9b 3b7cdc02 00e3febc 00e3febc vcllo!SVMain+0x23 [c:\git\libo\vcl\source\app\svmain.cxx @ 216]
00e3ff04 004014d9 00e3ff18 00401479 040f5f18 sofficeapp!soffice_main+0xab [c:\git\libo\desktop\source\app\sofficemain.cxx @ 67]
00e3ff0c 00401479 040f5f18 00e3ff30 004014b8 soffice!sal_main+0x9 [c:\git\libo\desktop\source\app\main.c @ 35]
00e3ff18 004014b8 00000003 040f5f18 040f5f18 soffice!main+0x19 [c:\git\libo\desktop\source\app\main.c @ 33]
00e3ff30 00401f5d 00400000 00000000 0005231e soffice!WinMain+0x28 [c:\git\libo\desktop\source\app\main.c @ 33]
00e3ffc0 7c817077 00000000 00000000 7ffd8000 soffice!__tmainCRTStartup+0x140 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 578]
00e3fff0 00000000 0040213c 00000000 00905a4d kernel32!BaseProcessStart+0x23

-----worker thread
   8  Id: 1244.1788 Suspend: 0 Teb: 7ffae000 Unfrozen
ChildEBP RetAddr  Args to Child              
11d2fb14 7c90df5a 7c919b23 00000488 00000000 ntdll!KiFastSystemCallRet
11d2fb18 7c919b23 00000488 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc
11d2fba0 7c901046 000f6638 10005990 040f6638 ntdll!RtlpWaitForCriticalSection+0x132
11d2fba8 10005990 040f6638 040f6638 11d2fbc4 ntdll!RtlEnterCriticalSection+0x46
11d2fbb8 02851cff 040f6638 11d2fbd0 02be8a6c sal3!osl_acquireMutex+0x40 [c:\git\libo\sal\osl\w32\mutex.c @ 81]
11d2fbc4 02be8a6c 040f6618 11d2fbe0 02835aa2 vcllo!vcl::SolarMutexObject::acquire+0xf [c:\git\libo\vcl\source\app\solarmutex.cxx @ 44]
11d2fbd0 02835aa2 040f6618 11d2fc2c 11d2fc40 vcllo!SalYieldMutex::acquire+0xc [c:\git\libo\vcl\win\source\app\salinst.cxx @ 141]
11d2fbe0 0b74326e 4f1adfb7 00000000 11d2fbdc vcllo!SolarMutexGuard::SolarMutexGuard+0x22 [c:\git\libo\solver\wntmsci12.pro\inc\vcl\svapp.hxx @ 439]
11d2fc40 07f838bb 07b11dbc 11d2fc60 ff8f4716 sclo!ScAddInListener::modified+0x2e [c:\git\libo\sc\source\core\tool\addinlis.cxx @ 121]
11d2fc88 07f82806 07b13bc4 ff8f4706 0803dc08 BLPAPIAddIn_uno!com::telemetry::sheet::BLP_VolatileResult::newValue+0xdb [y:\src\extension\src\blp_volatileresult.cpp @ 81]
11d2fcc8 07f7e9ea 11df0980 11df0980 00000000 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 ffffffff blpapi3_32!blpapi_Session_getAbstractSession+0x95
11d2fe50 7c90d8ba ffffffff 0dd4ccc8 00000000 blpapi3_32!blpapi_Name_destroy+0x6315d
11d2fe78 0829cc9f 00000000 0829dde0 11d2ff08 ntdll!NtQueryPerformanceCounter+0xc
11d2ff48 0829ded9 08297fa2 0dd4ccc8 00000000 blpapi3_32!blpapi_Name_destroy+0x7e30f
11d2ff4c 08297fa2 0dd4ccc8 00000000 00000000 blpapi3_32!blpapi_Name_destroy+0x7f549
11d2ff70 082c24fd 0dd42ca0 ff97fc8c 00000000 blpapi3_32!blpapi_Name_destroy+0x79612
00000000 00000000 00000000 00000000 00000000 blpapi3_32!blpapi_Name_destroy+0xa3b6d


----!locks result
0:000> !locks

CritSec +40f6638 at 040f6638
LockCount          2
RecursionCount     2
OwningThread       1504
EntryCount         19
ContentionCount    19
*** Locked

---!threads
0:000> !threads
Index TID TEB StackBase StackLimit DeAlloc StackSize ThreadProc
0 00001504 0x7ffdf000 0x00e40000 0x00e0e000 0x004b0000 0x00032000 0x40213c: soffice!WinMainCRTStartup
1 000015ec 0x7ffde000 0x05820000 0x0581f000 0x04e90000 0x00001000 0x10004930: sal3!rtl_cache_wsupdate_all
2 000006d8 0x7ffdd000 0x061b0000 0x061ad000 0x05820000 0x00003000 0x4ec67456: GdiPlus!BackgroundThreadProc
3 00000884 0x7ffdb000 0x08db0000 0x08daf000 0x08420000 0x00001000 0x7854345e: msvcr90!_endthreadex
4 00000280 0x7ffda000 0x0abc0000 0x0abbf000 0x0a230000 0x00001000 0x77e76c7d: rpcrt4!ThreadStartRoutine
5 00001750 0x7ffd9000 0x0b550000 0x0b54f000 0x0abc0000 0x00001000 0x774fe4ef: ole32!CRpcThreadCache::RpcWorkerThreadEntry
6 00000918 0x7ffd4000 0x10a10000 0x10a0f000 0x10080000 0x00001000 0x71a5d2c6: mswsock!SockAsyncThread
7 00000718 0x7ffaf000 0x113a0000 0x1139f000 0x10a10000 0x00001000 0x82c2523: blpapi3_32!blpapi_Name_destroy
8 00001788 0x7ffae000 0x11d30000 0x11d2b000 0x113a0000 0x00005000 0x82c2523: blpapi3_32!blpapi_Name_destroy
9 000010ec 0x7ffdc000 0x128c0000 0x128be000 0x11f30000 0x00002000 0x7854345e: msvcr90!_endthreadex
10 0000152c 0x7ffad000 0x13250000 0x1324f000 0x128c0000 0x00001000 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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
anwen anwen
Reply | Threaded
Open this post in threaded view
|

Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values

This post was updated on .
In reply to this post by Eike Rathke-2
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.

The bug link is : https://bugs.freedesktop.org/show_bug.cgi?id=53008
This is the first time that I submitted a LibreOffice bug. Can I assign it to you?

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<XResultLisenter> -> 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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
anwen anwen
Reply | Threaded
Open this post in threaded view
|

Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values

In reply to this post by Eike Rathke-2
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<XResultLisenter> -> 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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Eike Rathke-2 Eike Rathke-2
Reply | Threaded
Open this post in threaded view
|

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

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

attachment0 (205 bytes) Download Attachment
anwen anwen
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Eike Rathke-2 Eike Rathke-2
Reply | Threaded
Open this post in threaded view
|

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

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

attachment0 (205 bytes) Download Attachment
anwen anwen
Reply | Threaded
Open this post in threaded view
|

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<XTerminateListener> 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<XSpreadsheetDocument> 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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Meeks-2 Michael Meeks-2
Reply | Threaded
Open this post in threaded view
|

Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values

In reply to this post by anwen
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.

--
[hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Stahl-2 Michael Stahl-2
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Meeks-2 Michael Meeks-2
Reply | Threaded
Open this post in threaded view
|

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.

--
[hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values

In reply to this post by Michael Stahl-2
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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
anwen anwen
Reply | Threaded
Open this post in threaded view
|

Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values

This post was updated on .
In reply to this post by sberg
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, :-(

From the above discussion, it seems that release the SolarMutex is not a good idea. I also would like to try other method firstly, such as throwing an XTerminationVetoException. Honestly, I am not quite understanding the following explanation:

"If a XTerminateListener use this exception for a veto against the termination of the office, he will be the new "owner" of it. After his own operation will be finished, he MUST try to terminate the office again."  How to catch up the returned handler or something in the new "Owner" (XterminationListener object?). Although I could set up a status change, throw an exception, and stop the worker thread by itself when seeing the status change, I prefer to throw the exception, catch up the exception, and stop the worker thread from my another thread without SolarMutex. Please correct me if I am wrong.

Thank you,
Wendi


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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
anwen anwen
Reply | Threaded
Open this post in threaded view
|

Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values

In reply to this post by anwen
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<XSpreadsheetDocument> 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> xModel = UnoRuntime.queryInterface(XModel.class, uno::UNO_QUERY);
        Reference<XSpreadsheetDocument> 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<XDocumentEventListener*>(new CalcListener()), UNO_QUERY);
                        xBroadcaster->addDocumentEventListener(xDocListener);
                        std::cout << "added an DocEvtListener" << std::endl;
                }
        }
}

Thanks a lot.
Michael Stahl-2 Michael Stahl-2
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
anwen anwen
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
anwen anwen
Reply | Threaded
Open this post in threaded view
|

Re: Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values

In reply to this post by sberg
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
Next » 12