Issue 63473 - Clean process termination
Summary: Clean process termination
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: 680m159
Hardware: All All
: P3 Trivial (vote)
Target Milestone: AOO PleaseHelp
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2006-03-22 10:09 UTC by Stephan Bergmann
Modified: 2017-05-20 11:31 UTC (History)
2 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Stephan Bergmann 2006-03-22 10:09:22 UTC
Fixing issue 63397, I stumbled once again over problems of clean process
termination.  There, a unopkg process has a remote UNO connection open, releases
all remote objects (which leads to async release calls in additional threads),
calls exit from the main thread, which will forcefully terminate the additional
threads (which, btw, still operate while the atexit handlers run, which was the
problem in issue 63397).

A cleaner scenario would be that a process (soffice, unopkg, uno, whatever)
terminates once all threads have terminated.  To do this, a program must not
return from main or call exit, _exit, _Exit, but instead call pthread_exit or
ExitThread (Windows) from the main thread before it reaches the end of main
(remember to give all local vars of a C++ main a chance to be destroyed before
the call to pthread_exit/ExitThread; that pthread_exit from main is ok is
explicitly mentioned in Butenhof's book; that ExitThread from main is ok is
alluded to on the corresponding msdn web page; it must still be checked whether
exit is called implicitly once no more threads are there on Windows, as is the
case for Posix).  There are a few issues, however:

1  The vos OTimerManager thread never terminates.  This should be replaced with
some implementation that terminates the thread if it is not used.

2  The binary URP worker threads idle around for some time before they
terminate, waiting for new work to come in.  This causes a delay when
terminating a process.

For fixing issue 63397, changes were made to
bridges/source/remote/context/context.cxx: l. 179 ff and
cppu/source/uno/lbmap.cxx: l. 195 ff, allocating objects on the heap
(and leaking them) instead of statically (and destroying them through atexit
handlers).  These two changes should be reverted once this issue is fixed.
Comment 1 Stephan Bergmann 2006-03-22 10:11:04 UTC
Comment 2 Stephan Bergmann 2006-05-12 10:40:51 UTC
Also take into account the effect of sal/rtl/source/alloc_global.c:1.3 l. 169--174

  #if defined(__GNUC__)
  static void rtl_memory_fini (void) __attribute__((destructor));
  #elif defined(__SUNPRO_C) || defined(__SUNPRO_CC)
  #pragma fini(rtl_memory_fini)
  static void rtl_memory_fini (void);
  #endif /* __GNUC__ || __SUNPRO_C */

with respect to when exactly functions marked __attribute__((destructor)) or
#pragma fini are called.  Currently (i.e., when exiting from main calls exit,
and other threads can still run), this may cause threads to call
rtl_allocateMemory after rtl_memory_fini has been called, and rtl_allocateMemory
returns NULL in such a case (seen on SRC680m169
Comment 3 kay.ramme 2006-05-12 11:05:57 UTC
KR->SB: IMHO, it can be expected that the _fini section of a shared object is
only be called directly before unloading the shared object. Do you have any
contrary experiences?
Comment 4 Stephan Bergmann 2006-05-12 11:55:16 UTC
"the destructor attribute causes the function to be called automatically after
main () has completed or exit () has been called."  I do not know whether and
how this relates to ELF fini sections.
Comment 5 kay.ramme 2006-05-12 12:24:14 UTC
This relates to _fini sections, as the destructors of global/static values are
called out of _fini sections. There is AFAIK no direct relationship to the
return of main (except if this calls "exit" implicitly). "exit" is AFAIK another
beast and terminates the process independent of the existance of other threads.
However, your proposed solution of utilizing "pthread_exit" to terminate the
"main" calling thread before actually leaving main seems still to be valid and
should _not_ conflict with the usage of "__attribute__((...structor))" for
de-/initializing the memory subsystem.
Comment 6 Stephan Bergmann 2006-05-12 13:02:03 UTC
"[...] should _not_ conflict with [...]"  Exactly that has to be evaluated (I do
not know how the __attribute__((destructor)) feature is implemented, so I would
like to find this out instead of speculating).
Comment 7 Stephan Bergmann 2009-04-15 12:54:40 UTC
"For fixing issue 63397, changes were made to [...]
cppu/source/uno/lbmap.cxx: l. 195 ff [...].  These [...] changes should
be reverted once this issue is fixed."  In issue 92131,
cws/sb109/cppu/source/uno/lbmap.cxx@270841 was further simplified (by completely
removing ~MappingsData), which would also need to be reverted.
Comment 8 Stephan Bergmann 2010-07-02 15:01:05 UTC
"For fixing issue 63397, changes were made to
bridges/source/remote/context/context.cxx: l. 179 ff": these have
effectively been reverted through issue 112784.
Comment 9 Marcus 2017-05-20 11:31:28 UTC
Reset assigne to the default "".