text: Apache OpenOffice (AOO) Bugzilla – Issue 63473
  Clean process termination
  Last modified: 2017-05-20 11:31:28 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:1.6.20.1 l. 179 ff and
  cppu/source/uno/lbmap.cxx:1.23.28.1 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.
  .
  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 unxlngi6.pro).
  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?
  <>:
  "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.
  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.
  "[...] 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).
  "For fixing issue 63397, changes were made to [...]
  cppu/source/uno/lbmap.cxx:1.23.28.1 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.
  "For fixing issue 63397, changes were made to
  bridges/source/remote/context/context.cxx:1.6.20.1 l. 179 ff": these have
  effectively been reverted through issue 112784.
  Reset assigne to the default "issues@openoffice.apache.org".