On 09.06.2015 10:02, Noel Grandin wrote: > On 2015-06-09 09:58 AM, Stephan Bergmann wrote: >> On Windows, with master as of last night, "make check" happened to run into >> a deadlock in soffice.bin as below. The >> main thread is trying to re-acquire the SolarMutex (after a >> SolarMutexReleaser) from within the event loop, while an >> incoming URP thread (apparently holding the SolarMutex) does >> vcl::Window::dispose which, on Windows, blocks on sending a >> message into the event loop.
this started happening for me in sc_unoapi on a --enable-dbgutil build almost always since half a year or so; before that it was less likely for whatever reason but still did happen. (the deadlock moved from ~Window to Window::dispose due to VclPtr refactoring.) the deadlock does not appear easily fixable; the last slide of my threading talk last year was about it actually. this requires a larger re-design; either handling all VCL stuff only on the main thread so that other threads never call Window methods, or perhaps it would also work to have a dedicated thread that does nothing other than handle the special thread affine Win32 create/destroy-window messages and never takes a lock. > Shouldn't something that blocks on sending a message into the event loop drop > the SolarMutex while it waits for the > reply, and then reacquire it afterwards? no. this is deep inside VCL internals which are very likely not in a consistent state at this point, so other threads must be prevented from calling into VCL. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
