Bug 122871 - soffice process hanging on exit (mutex related)
Summary: soffice process hanging on exit (mutex related)
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
6.1.4.2 release
Hardware: All OpenBSD
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Exit
  Show dependency treegraph
 
Reported: 2019-01-22 08:40 UTC by Robert Nagy
Modified: 2022-11-30 03:47 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Nagy 2019-01-22 08:40:29 UTC
Description:
There has been a bug that has been annoying me for some time now.
Whenever exiting the soffice UI the UI closes, but then the soffice process
is lurking around in sleep mode, probably waiting for on a mutex.

On exit Desktop::DeInit() is called which calls RequestHandler::Disable() for
and the process gets stuck in there.

#1  0x0000014efd92ef6b in _sem_wait (sem=0x14f122f1240, can_eintr=0, abstime=0x0, delayed_cancel=0x14efeb676d0 <_initial_thread+200>) at /usr/src/lib/librthread/synch.h:41
#2  0x0000014efd9301fb in pthread_join (thread=0x14f122f1240, retval=0x0) at /usr/src/lib/librthread/rthread.c:304
#3  0x0000014ec411b345 in desktop::RequestHandler::Disable() () from /usr/local/lib/libreoffice/program/libsofficeapp.so
#4  0x0000014ec40ee26b in desktop::Desktop::DeInit() () from /usr/local/lib/libreoffice/program/libsofficeapp.so
#5  0x0000014eaafc1c05 in DeInitVCL() () from /usr/local/lib/libreoffice/program/libvcllo.so
#6  0x0000014eaafc1310 in ImplSVMain() () from /usr/local/lib/libreoffice/program/libvcllo.so
#7  0x0000014eaafc26d3 in SVMain() () from /usr/local/lib/libreoffice/program/libvcllo.so
#8  0x0000014ec41200c1 in soffice_main () from /usr/local/lib/libreoffice/program/libsofficeapp.so
#9  0x0000014c56927331 in main ()

In the Desktop::Init() function ::Disable is only called on some specific
process types and doing the same in ::DeInit fixes the issue for me.
I don't know if this is the right way but here is the patch that I am
running with now:

--- desktop/source/app/app.cxx.orig
+++ desktop/source/app/app.cxx
@@ -551,6 +551,7 @@ void Desktop::InitFinished()

 void Desktop::DeInit()
 {
+    const CommandLineArgs& rCmdLineArgs = GetCommandLineArgs();                                                     
     try {
         // instead of removing of the configManager just let it commit all the changes                              
         utl::ConfigManager::storeConfigItems();
@@ -567,7 +568,9 @@ void Desktop::DeInit()
         // clear lockfile
         m_xLockfile.reset();

-        RequestHandler::Disable();
+        if ( !rCmdLineArgs.GetUnknown().isEmpty()
+                  || rCmdLineArgs.IsHelp() || rCmdLineArgs.IsVersion() )                                            
+            RequestHandler::Disable();
         if( pSignalHandler )
             osl_removeSignalHandler( pSignalHandler );
     } catch (const RuntimeException&) {


Steps to Reproduce:
1. Exit LibreOffice on OpenBSD
2.
3.

Actual Results:
Process hangs.

Expected Results:
Process should exit.


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Xisco Faulí 2019-06-10 16:52:12 UTC
Hello Robert,
Thanks for the detailed report.
Would you mind submitting a patch to gerrit so the developers can review it ? Please see https://wiki.documentfoundation.org/Development/gerrit
Comment 2 Xisco Faulí 2019-10-21 12:27:05 UTC Comment hidden (obsolete)
Comment 3 Robert Nagy 2019-10-21 14:13:42 UTC
(In reply to Xisco Faulí from comment #2)
> Hi Robert Nagy,
> Is it fine if we submit the patch on your behalf ?

Hi

Please do.
Comment 4 QA Administrators 2019-10-22 02:33:38 UTC Comment hidden (obsolete)
Comment 5 Xisco Faulí 2020-07-17 11:13:42 UTC
Hi Stephan,
I thought you might be interested in this issue
Comment 6 Stephan Bergmann 2020-07-23 16:00:39 UTC
(In reply to Robert Nagy from comment #0)
> Description:
> There has been a bug that has been annoying me for some time now.
> Whenever exiting the soffice UI the UI closes, but then the soffice process
> is lurking around in sleep mode, probably waiting for on a mutex.
> 
> On exit Desktop::DeInit() is called which calls RequestHandler::Disable() for
> and the process gets stuck in there.
> 
> #1  0x0000014efd92ef6b in _sem_wait (sem=0x14f122f1240, can_eintr=0,
> abstime=0x0, delayed_cancel=0x14efeb676d0 <_initial_thread+200>) at
> /usr/src/lib/librthread/synch.h:41
> #2  0x0000014efd9301fb in pthread_join (thread=0x14f122f1240, retval=0x0) at
> /usr/src/lib/librthread/rthread.c:304
> #3  0x0000014ec411b345 in desktop::RequestHandler::Disable() () from
> /usr/local/lib/libreoffice/program/libsofficeapp.so
> #4  0x0000014ec40ee26b in desktop::Desktop::DeInit() () from
> /usr/local/lib/libreoffice/program/libsofficeapp.so
> #5  0x0000014eaafc1c05 in DeInitVCL() () from
> /usr/local/lib/libreoffice/program/libvcllo.so
> #6  0x0000014eaafc1310 in ImplSVMain() () from
> /usr/local/lib/libreoffice/program/libvcllo.so
> #7  0x0000014eaafc26d3 in SVMain() () from
> /usr/local/lib/libreoffice/program/libvcllo.so
> #8  0x0000014ec41200c1 in soffice_main () from
> /usr/local/lib/libreoffice/program/libsofficeapp.so
> #9  0x0000014c56927331 in main ()

The relevant part is why the thread running PipeIpcThread::execute (desktop/source/app/officeipcthread.cxx) does not finish.  Better provide a backtrace of all threads still running when soffice.bin gets stuck for you.

> In the Desktop::Init() function ::Disable is only called on some specific
> process types and doing the same in ::DeInit fixes the issue for me.

Those two calls to RequestHandler::Disable from Desktop::Init and Desktop::DeInit are not meant to be symmetric.  For a "normal" invocation of soffice, your patch will just fail to join any still-running PipeIpcThread (which can have bad consequences of its own); it does not address the root issue why that pthread_join blocks for you.
Comment 7 Buovjaga 2020-11-30 14:44:46 UTC
(In reply to Stephan Bergmann from comment #6)
> The relevant part is why the thread running PipeIpcThread::execute
> (desktop/source/app/officeipcthread.cxx) does not finish.  Better provide a
> backtrace of all threads still running when soffice.bin gets stuck for you.

Robert: can you provide such a backtrace?
Comment 8 Albina 2021-12-09 15:24:14 UTC Comment hidden (spam)
Comment 9 Xisco Faulí 2022-05-02 11:59:09 UTC
Thanks for reporting this issue.
Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Comment 10 QA Administrators 2022-10-30 03:46:45 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2022-11-30 03:47:44 UTC
Dear Robert Nagy,

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