https://bugs.documentfoundation.org/show_bug.cgi?id=96887
Michael Stahl <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected], | |[email protected] --- Comment #7 from Michael Stahl <[email protected]> --- okay, with ALG's help i could reproduce this, though not very often. it happens on CppunitTest_sc_subsequent_export_test, with something else running (make check) to add more load. there are several aspects to this problem, which is fundamentally that the main thread's message queue fills up. 1. main thread retrieves some message and dispatches it, gets stuck in ImplSalYieldMutexAcquireWithWait() on GetMessage() holding mpSalWaitMutex 2. some timers go wild and post thousands of these messages 1186 = SAL_MSG_TIMER_CALLBACK (WM_USER+162) 3. pool threads in SalYieldMutexRelease() tries to PostMessage(SAL_MSG_RELEASEWAITYIELD) but the queue is full already and the result of PostMessage isn't checked so no message is posted; thread waits for main thread to release mpSalWaitMutex 4. deadlock ALG has a plan to replace this SAL_MSG_RELEASEWAITYIELD with something better, it turns out that there's a MsgWaitForMultipleObjects() function that can wait for either a mutex (i.e. SalYieldMutex's m_mutex) to be available or (with QS_SENDMESSAGE) a SendMessage() to come in, or a timeout, so that should cover all cases and we should be able to get rid of mpSalWaitMutex. that would fix this deadlock. however the fact that the message queue can fill up in these parallel file import tests is concerning; other PostMessages could get lost and we basically never check that PostMessage() succeeds. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
