Apache OpenOffice (AOO) Bugzilla – Issue 113979
getUnloadingMutex() uses already destructed object during process exit
Last modified: 2017-05-20 11:35:16 UTC
While debugging a deadlock during process shutdown, we found out the following: -the process being exited still had a Reference<> to an object in another process as static variable -__cxa_finalizers are currently running, and have already destroyed the static mutex within the getUnloadingMutex() function (in unload.cxx) -__cxa_finalizer now destroys the static Reference<> object, causing an infinite hang when locking the unloading mutex, since it was already destroyed. In sal/osl/unx/mutex.c, the osl_getGlobalMutex had the same problem. It was fixed by using pthread_once to initialize the mutex without ever destroying it. We should do this here too, or allocate the unloading mutex on the heap (causing a memory leak, but no hang).
Stack trace showing the issue: #0 0x0000003cb680ce74 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x0000003cb6808874 in _L_lock_106 () from /lib64/libpthread.so.0 #2 0x0000003cb68082e0 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002ac15410868a in osl_acquireMutex () #4 0x00002ac1541036d4 in osl::Mutex::acquire () #5 0x00002ac15410372b in osl::Guard<osl::Mutex>::Guard () #6 0x00002ac1541393d2 in rtl_moduleCount_release () #7 0x00002ac18bd5d328 in RemoteEnvironment_thisDisposing () #8 0x00002ac153ea9ff0 in defenv_release () #9 0x00002ac18bd7b5a5 in bridges_remote::RemoteMapping::~RemoteMapping () #10 0x00002ac18bd7b918 in bridges_remote::freeRemoteMapping () #11 0x00002ac153e99a0f in uno_revokeMapping () #12 0x00002ac18bd7b857 in thisRelease () #13 0x00002ac18bd79aae in com::sun::star::uno::Mapping::~Mapping () #14 0x00002ac18bd78790 in bridges_remote::Remote2UnoProxy::~Remote2UnoProxy () #15 0x00002ac18bd79a64 in bridges_remote::freeRemote2UnoProxy () #16 0x00002ac153ea9b93 in s_stub_defenv_revokeInterface () #17 0x00002ac153eafecf in s_environment_invoke_v () #18 0x00002ac153eaff61 in uno_Environment_invoke_v () #19 0x00002ac153eb004a in uno_Environment_invoke () #20 0x00002ac153ea990f in defenv_revokeInterface () #21 0x00002ac18bd79a3a in bridges_remote::releaseRemote2UnoProxy () #22 0x00002ac18956392b in bridges::cpp_uno::shared::freeCppInterfaceProxy () #23 0x00002ac153ea9b93 in s_stub_defenv_revokeInterface () #24 0x00002ac153eafecf in s_environment_invoke_v () #25 0x00002ac153eaff61 in uno_Environment_invoke_v () #26 0x00002ac153eb004a in uno_Environment_invoke () #27 0x00002ac153ea990f in defenv_revokeInterface () #28 0x00002ac18956361c in bridges::cpp_uno::shared::CppInterfaceProxy::releaseProxy () #29 0x00002ac1895603ae in cpp_vtable_call () #30 0x00002ac189561f16 in privateSnippetExecutor () #31 0x00002ac14f6387f4 in com::sun::star::uno::Reference<com::sun::star::uno::XInterface>::~Reference () from libtest.so #32 0x00002ac14f62eade in __tcf_12 () #33 0x0000003cb5c3363e in __cxa_finalize () from /lib64/libc.so.6 #34 0x00002ac14f4cf3b6 in __do_global_dtors_aux () #35 0x0000000000000000 in ?? ()
anybody already know this one? assigning to sb
I think its issue 107490 again
Yeah you're right, its related to 107490. However, the patch there didn't include the unloading mutex.
.
Reset assigne to the default "issues@openoffice.apache.org".