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?
<http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Function-Attributes.html#index-g_t_0040code_007bdestructor_007d-function-attribute-1614>: "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".